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SECTION  1 - INTRODUCTION 
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I ! 


1.1  GENERAL 

This  report  is  a presentation  of  a system  study  and  outlines  a recommended 
approach  to  an  operational  unified  system  control  mechanism  for  the  near-term 
overseas  Defense  Communications  System  (DCS).  An  interim  report  dated  April  1977 
described  in  general  terms  the  recommended  approach  together  with  detailed 
functional  flow  diagrams  showing  the  information  gathering,  processing  and  flow 
required  for  implementation.  This  final  report  includes  a summary  of  the  interim 
report  together  with  a detailed  description  of  the  functional  requirements,  data  base 
requirements,  software  and  hardware  considerations  including  sizing  and  loading 
for  each  level  of  the  system  control  hierarchy.  Also  included  are  recommended 
figures  of  merit  (FOMs)  for  assessing  the  performance  of  the  overseas  DCS. 

1.2  PURPOSE 


The  prime  reason  for  implementing  a system  of  the  type  described  herein  is  to 


improve  the  operational  effectiveness  of  the  DCS  and  each  DCS  system  control  level 
by  integrating  the  transmission  and  switched  network  controls  and  provide  a nucleus 
for  the  integration  and  interfacing  of  ongoing  programs  associated  with  system, 
subsystem  and  network  control. 

1.3  SCOPE 

The  scope  of  this  task  encompasses  an  analysis  of  the  present  overseas  DCS 
transmission  media,  network  and  traffic  control  methods  and  procedures  and 
development  of  a recommended  unified  system  control  mechanism  for  the  near-term 
overseas  DCS.  The  analysis  addresses  the  existing  transmission  systems,  AUTOVON, 
AUTODIN  (I),  AUTOSEVOCOM  (I),  and  special  circuits  which  restricts  this  study  to 
the  current  complement  of  DCS  equipment  in  the  field.  Planned  systems,  such  as 
AUTODIN  (II),  AUTOSEVOCOM  (II),  and  planned  control  improvements,  such  as 
RTAC  for  DSCS,  are  subjects  for  future  study.  The  effort  encompasses  developing  a 
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unified  system  control  configuration  responsive  to  the  needs/requirements  of  the 
various  control  levels  of  the  DCS,  identification  of  the  functions  to  be  performed  at 
each  level,  and  the  hardware/software  capability  required  in  support  of  these 
functions. 

1.  4 APPROACH  TO  THE  TASK 
1.4.1  Approach 

The  initial  effort  was  directed  toward  identification  and  analysis  of  the  near- 
term  overseas  DCS  system  control  structure  and  includes  transmission  media  and 
switched  networks.  The  intention  was  to  identify  specific  sources  for  the  collection 
and  correlation  of  data  required  for  system  control  and  network  traffic  management. 

The  results  of  this  initial  effort  were  used  to  develop  a unified  system  control 
configuration.  This  effort  included  the  identification  of  the  general  information  flow 
requirements  and  controls  to  be  exercised  at  each  control  level  together  with  the 
required  interface  and  interplay  among  switched  networks  and  transmission  media. 
Functional  flow  diagrams  were  then  developed  in  support  of  the  unified  system  control 
configuration  to  show  the  information  gathering,  processing  and  flow  required. 
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These  functional  flow  diagrams  and  the  supporting  documentation  were 
presented  in  a report  titled  "Unified  Network/ Traffic  Transmission  Media  Control 
(Interim  Report)"  dated  April  1977  which  forms  the  baseline  for  the  remainder  of 
the  program. 


Having  identified  a unified  systen.  control  configuration  and  the  functions 
required  to  be  exercised  at  each  level  of  the  DCS  control  structure,  the  next  step 
concerned  the  hardware  and  software  capabilities  required  to  support  the  identified 
configuration. 


Four  levels  where  processing  capability  is  required  were  identified.  These 
are  the  ACOC,  the  Sector,  the  Node  and  the  AUTOVON  Switch.  A oata  base  str  icture 
was  developed  for  each  level  to  satisfy  the  data  storage  requirements  in  support  of 
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the  functions  identified  in  the  functional  flowcharts.  Every  effort  was  made  to 
ensure  that  the  data  base  structure  was  similar  to  that  envisioned  for  the  ATEC 
system,  especially  since  the  connectivity  directory  data  is  very  similar  to  that 
required  by  ATEC;  thus  keeping  open  the  possibility  of  shared  or  common  data  bases. 

Next  a preliminary  software  design  was  performed  in  order  to  size  the  software 
system  and  a sizing  analysis  for  each  level  of  the  unified  system  control  was 
performed.  Finally,  hardware  and  software  costing  estimates  were  developed  for 
each  level  together  with  a total  hardware/software  estimated  for  the  European  theater. 

The  methodology  employed,  and  assumptions  made  in  developing  the  unified 
system  control  mechanism  are  presented  with  their  respective  work  elements  in  the 
appropriate  sections  of  this  report,  and  need  not  be  repeated  here.  However, 
because  of  the  relative  complexity  and  magnitude  of  the  software  sizing  work 
element,  a detailed  software  sizing  methodology  is  presented  in  the  following  para- 
graph. This  is  intended  to  familiarize  the  reader  with  the  basic  design  concept  and 
insure  a fuller  appreciation  of  the  software  sizing  analysis  sections. 

1.4.2  Software  Sizing  Methodology 

In  the  following  sections  of  this  report  descriptions  of  suggested  functional 
capabilities  and  preliminary  softwa'e  system  designs  supporting  those  capabilities 
are  presented  for  each  level  of  the  unified  control  hierarchy.  A preliminary  soft- 
ware design  is  a necessary  step  in  performing  a sizing  analysis  of  this  magnitude. 

By  performing  this  step,  commonalities  in  functional  software  can  be  more  easily 
recognized  and  considered  in  the  overall  sizing  estimate. 

The  THREADS  design  methodology  was  employed  in  the  design  of  the  unified 
control  system  software.  THREADS  is  a CSC-developed  methodology  and  discipline 
for  assisting  system  design,  development,  verification,  testing,  and  management. 
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The  initial  step  in  the  THREADS  design  process  is  the  identification  of  a set  of 
system  level  requirements.  The  system  level  requirements  for  each  unified  control 
element  are  considered  as  well  as  the  requirements  for  the  overall  system.  Using 
these  requirements,  a set  of  external  system  stimuli  and  system  responses  are 
defined.  The  stimuli  serve  to  identify  a set  of  external  interfaces  to  each  level  of  the 
unified  control  processing  system  including  peripheral  interfaces  and  real-time  data 
sources  (i.e. , ATEC).  The  expected  responses  determine  the  processing  that  must 
be  performed.  The  system  level  requirements,  external  stimuli  and  system  responses 
define  a set  of  system  THREADS.  Each  THREAD  identifies  a unique  stimulus  pro- 
cessing response  activity.  For  example,  the  receipt  of  communications  channel  input 
interrupt  is  a stimulus  to  the  THREAD  which  controls  the  data  transfer  from  the 
channel  into  the  processor's  memory.  The  processing  in  this  THREAD  involves 
interface  handling  and  buffer  control.  The  response  to  this  THREAD  is  the  received 
data  residing  in  a specified  portion  of  memory  and  necessary  control  operations  for 
scheduling  the  data  for  additional  processing.  Figure  1-1  shows  the  standard 
schematic  representation  for  a THREAD. 


In  addition  to  the  stimulus-processing-response  information,  a THREAD 
includes  a list  of  software  modules  used  to  implement  each  of  its  processing  tasks. 
This  provides  a means  of  mapping  system  processing  requirements  to  unique  sets  of 
software. 


After  addressing  all  external  stimuli  and  related  THREADS,  a set  of  THREADS 
are  identified  which  support  internal  system  stimuli.  For  example,  in  the  communi- 
cations handling  THREAD  described  earlier,  one  of  the  responses  is  the  scheduling  of 
data  for  subsequent  processing.  That  response  serves  as  a stimulus  for  a second 
THREAD  which  performs  the  processing.  In  this  case,  the  stimulus  is  of  an  internal 
nature,  generated  by  the  software  itself. 
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Figure  1-1.  Schematic  Representation  of  a 
THREAD 


After  the  design  progresses  to  the  stage  where  a complete  set  of  THREADS  is 
defined,  the  THREADS  are  gathered  into  ordered  sets.  The  sets  may  be  hierarchi- 
cally structured  to  show  the  relationships  between  groups  of  THREADS  and  the  system 
elements  or  functions  that  they  support.  The  THREADS  contained  in  the  software 
description  sections  of  this  report  are  presented  in  this  manner  so  that  the  capabilities 
available  to  each  unified  control  element  are  summarized  by  the  THREAD  hierarchies. 

In  order  to  size  the  software  system,  the  routines  identified  during  the  design 
of  the  AUTOVON  Switch  Station  Level  Module,  Node,  Sector,  and  ACOC  subsystems 
are  gathered  into  four  computer  program  hierarchies.  Additionally,  each  routine  is 
summarized  in  a sizing  table  which  states  the  basic  function  of  the  routine,  an 
estimate  of  the  size  of  the  routine  in  lines  of  code,  and  core  requirements  for  the 
routine  and  significant  data  associated  with  the  routine.  The  core  requirement  for 
each  routine  is  based  on  an  expansion  ratio  of  15  bytes  of  core  for  each  line  of  HOL 
code.  This  ratio  for  a 16-bit  word  length  minicomputer  is  derived  from  two  com- 
ponents. First,  it  is  assumed  that  the  average  HOL  statement  expands  into  5 assembly 
level  instructions.  This  expansion  is  commonly  experienced  when  using  moderately 
complex  statements  with  currently  available  minicomputer  compilers.  Second,  it  is 
assumed  that  the  average  assembly  level  instruction  requires  3 bytes  of  storage. 

This  expansion  is  also  commonly  experienced  since  moderately  optimized  code 
consists  of  roughly  one-half  memory  reference,  one-half  register -register  or  other 
single  word  operations.  Typical  memory  referencing  instructions  require  two  words 
of  storage.  The  combined  effect  of  these  two  components  is  a 15  byte  expansion 
ratio  for  each  line  of  HOL. 

Once  the  individual  routine  sizes  are  determined,  the  processor  memory 
requirements  can  be  determined  by  structuring  the  routines  into  overlay  classes. 

The  minimum  processor  memory  requirement  is  reduced  in  this  way  since  only  the 
necessary  software  to  perform  a specific  function  is  in  core  at  any  time.  The  use  of 
overlays  is  addressed  in  the  software  sizing  sectors  since  random  access  storage  for 
on-line  storage  of  the  overlays  is  available  at  all  levels  of  unified  system  control. 
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SECTION  2 - SYSTEM  DESCRIPTION 


2.1  GENERAL 

This  section  presents  a brief  summary  of  the  equipment  configuration  and 
information  flow  as  presented  in  the  interim  report  titled  "Unified  Network  Traffic/ 
Transmission  Media  Control"  and  dated  April  1977.  In  addition  it  contains  an  introduc- 
tion to  the  detailed  functional  flowcharts  which  are  presented  in  Sections  3,  4,  and  5 of 
this  report.  Also  included  is  a description  of  the  man-machine  interface  and  displays 
required  in  support  of  the  System  operation. 

2.  2 FUNCTIONA  L INFORMATION  FLOW 

The  functional  information  within  the  theater  in  support  of  the  unified  system 
control  is  shown  in  Figure  2-1.  Functionally  this  flow  agrees  with  the  operations, 
maintenance  and  reporting  philosophies  already  implemented  and  with  the  ATEC  system 
operation  as  presently  envisioned.  The  levels  at  which  the  information  processing  and 
control  can  be  accomplished  for  both  transmission  systems  and  switched  networks  is 
indicated  in  this  figure. 

Switch  transmission-related  data  is  interfaced  with  purely  transmission  data  at  the 
node  level  and  shares  the  same  information  flow  to  the  sector  and  ACOC.  Thus  the  same 
communications  lines  can  be  used  for  both.  Switch  network  related  data  is  required  only 
at  the  switches  and  the  ACOC.  However  this  data  can  be  forwarded  through  the  nodes  and 
sectors  to  the  ACOC  sharing  the  same  communications  lines  as  the  switch  transmission 
related  data.  Refer  to  the  interim  report  dated  April  1977  for  details. 

2. 3 EQUIPMENT  CONFIGURATION  AND  FUNCTIONS 

The  basic  equipment  configuration  and  functions  required  in  support  of  the 
functional  information  flow  are  shown  in  Figure  2-2. 


CONTROL.'  DIRECTION 


Figure  2-2.  Unified  System  Control  Equipment  Configuration 


Information  flow  from  the  station  level  5 to  the  nodal  level  4 will  comprise 
coordination,  switch  transmission-related  equipment  status,  transmission  status, 
traffic  status  and  purely  switch  related  equipment  status.  The  later  two  categories  will 
not  be  subject  to  nodal  processing  but  will  simply  be  routed  through  the  nodal  level. 

The  switch  transmission-related  status  and  transmission  status  will  be  correlated  in 
the  nodal  processor,  stored,  updated,  and  forwarded  to  the  sector  as  combined  status. 
The  nodal  data  base  will  comprise  connectivity,  status  and  journaling  for  all  stations, 
links,  trunks  and  circuits  within  nodal  jurisdiction.  Operator  terminals  at  each  station 
will  permit  station  access  to  the  node  and  allow  the  node  to  request,  control  and  direct 
the  station  if  required. 

Several  nodal  processors  will  coordinate  with  and  report  to  the  sector  processor. 
As  with  the  nodal  processor,  the  sector  will  not  process  the  traffic  status  data  nor  the 
switch  equipment  status  data  but  will  route  the  same  to  the  ACOC  for  network  type 
assessment.  The  combined  station  information  derived  from  the  various  nodes  will  be 
processed,  stored  and  updated  at  the  sector  for  use  in  fault  isolation  and  determining 
the  need  for  reroute  action.  The  sector  processor  will  determine  the  need  for  broad- 
casting update  information  to  other  sectors  within  the  theater  and  will  process  and 
distribute  update  information  from  other  sectors  to  appropriate  nodes.  Interface  with 
the  respective  O&M  agencies  will  take  place  at  the  sector. 

The  sectors  will  forward  combined  status  summaries  to  the  ACOC  for  all  links, 
trunks  and  special  circuits  or  as  specified  by  the  ACOC.  The  ACOC  will  process  this 
information  together  with  the  traffic  status  and  switch  equipment  status  data  in  support 
of  network/traffic/transmission  assessment  and  control. 

2.  4 FUNCTIONA  L FLOWCHARTS 

Functional  flowcharts  illustrate  the  flow  of  information  from  the  station  level 
inputs  through  the  unified  control  system  hierarchy,  the  functions  and  control  decisions 
performed  at  each  level,  and  the  flow  of  the  control  directives  down  through  the  hier- 
archy. Figure  2-3  is  a generalized  flowchart  that  depicts  the  entire  unified  system 
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control  hierarchy.  This  illustration  shows  the  major  functional  groupings  at  each 
control  level  and  their  interrelationship.  Detailed  flowcharts  and  descriptions  for  each 
control  level  are  presented  within  their  respective  sections,  i.e. , station  and  node  are 
in  Section  3,  Sector  in  Section  4,  and  ACOC  in  Section  5. 

The  numbers  above  the  upper  right  hand  corner  of  the  blocks  refer  to  the  detailed 
flowchart  for  that  block,  i.e. , N3  refers  to  Sheet  3 of  the  nodal  level  flowchart.  These 
numbers  also  identify  the  groupings  of  blocks  as  to  the  level  where  the  functions  are 
performed.  ST,  N,  S and  A represent  the  station,  node,  sector,  and  ACOC  levels 
respectively. 

The  ATEC  system  structure  is  parallel  to  the  unified  system  control  structure 
with  the  point  of  interface  being  the  status  and  connectivity  data  base  which  both 
systems  will  share.  The  measurement  acquisition  and  fault  isolation  algorithms  of 
ATEC  will  operate  independently  with  the  unified  control  system  utilizing  the  results. 
This  type  of  architecture  allows  the  unified  control  structure  to  be  easily  adaptable  to 
adding  inputs  from  other  types  of  automatic  measurement  acquisition  systems  that  may 
be  added  in  the  future. 

2.5  MAN/MACHINE  INTERFACE 

The  exchange  of  information  between  the  technical/network  controllers  and  the 
processors  at  each  level  in  the  DCS  system  control  hierarchy  is  of  major  significance 
in  the  operation.  Technical  controllers  at  stations  must  have  the  capability  to  speedily 
input  fault  reports  and  subsequent  updates  to  the  node  processor  and  to  receive  fault 
status  summaries  and  special  requests  for  information  from  the  node.  Node  controllers 
must  be  capable  of  receiving  reports,  and  communications  with  Sector  controllers  and 
subordinate  station  technical  controllers  in  directing  restorals  and  fault  isolation. 

Sector  controllers  must  be  capable  of  receiving  reports  from  nodes  and  other  sectors 
and  of  communications  with  the  ACOC  controllers,  other  sector  controllers,  and 
subordinate  node  controllers.  ACOC  controllers  must  be  capable  of  receiving  reports 
from  sectors,  switches,  and  the  SATCOM  Controller  and  of  communications  with  other 
ACOCs,  and  subordinate  sector  controllers.  The  information  exchange  must  be 
optimized  in  form  and  format.  Sufficient  format  control  should  be  provided  to  cause 
information  request  and  response  to  be  in  plain  language 


information  request  and  response  to  be  in  plain  language  clearly  understandable  by 
controllers.  Each  request  from  a controller  position  to  the  processor  shall  be 
acknowledged  within  10  seconds. 

The  controller  terminals  at  the  ACOC,  Sectors  and  Nodes  should  provide  for 
visual  displays  and  keyboard  inputs  with  programmable  function  keys  to  facilitate 
information  requests.  A hard  copy  capability  is  also  required  at  the  above  levels. 

Station  controller  terminals  will  be  similar  to  those  at  higher  levels.  However,  the 
need  for  a hard  copy  at  stations  with  less  than  120  terminating  users  may  not  be 
necessary. 

2.6  DISPLAYS 

The  unified  system  control  configuration  shall  provide  the  capability  to  display 
information  at  the  ACOC,  Sector,  Node  and  Station  levels.  These  displays  should 
comprise  an  automatically  updated  display  for  summarized  system  status  for  use  by 
the  Node,  Sector  and  ACOC  controllers;  major  displays  on  request  to  satisfy  no  re 
detailed  status  requirements;  displays  for  preformatted  entry  of  data  by  controllers; 
and  displays  to  satisfy  the  need  for  special  requests.  The  information  to  be  displayed 
at  each  level  is  presented  in  Table  2-1  and  are  discussed  in  the  following  paragraphs. 

2.6.1  System  Status  Summary 

This  is  an  automatic  display  for  use  by  the  node,  sector  and  ACOC.  It  is  intended 
to  keep  the  controller  aware  of  the  status  of  that  portion  of  the  communications  system 
within  his  jurisdiction.  Figure  2-4  shows  a recommended  display  for  the  Nodes  and 
Sectors  which  are  primarily  transmission  oriented.  For  all  stations,  links,  trunks  and 
circuits  within  the  node  or  sector  area  of  responsibility,  the  number  of  current  outages 
and  degradations  will  be  constantly  displayed.  In  addition  as  new  faults  are  reported 
they  shall  appear  as  flashing  indicators  until  acknowledged  by  the  appropriate  controller. 
Thus  a node  may  show  6 circuit  outages,  2 of  which  have  not  yet  been  acknowledged. 

This  information  can  be  continuously  displayed  on  a monitor  for  a current  awareness 
of  system  conditions  and  to  alert  the  controller  for  the  need  to  request  additional 
details.  At  the  ACOC,  the  system  status  summary  monitor  will  include  switch  and 


Table  2-1 


Required  Displays  at  Each  DCS 
System  Control  Level 


DISPLAYS 

Stn 

Node 

Sector 

ACOC 

AUTOMATIC  DISPLAYS 

System  Status  Summary 

X 

X 

X 

MAJOR  DISPLAYS 

Detailed  Fault  Record 

X 

X 

X 

X 

Station  Fault  Summary 

X 

X 

X 

X 

Link  Fault  Summary 

X 

X 

X 

X 

Trunk  Fault  Summary 

X 

X 

X 

X 

Circuit  Fault  Summary 

X 

X 

X 

X 

Connectivity 

X 

X 

X 

X 

Switch  Status  Summary 

X 

AUTODIN  Traffic  Summary 

X 

AUTOVON  Switch/Traffic  Summary 

X 

Journal  Data 

X 

X 

X 

DISPLAYS  FOR  ENTERING  DATA 

Open  Fault 

X 

Update  Fault 

X 

X 

X 

Close  Fault 

X 

Report  HA  Z CON 

X 

Report  PMP/QA  Data 

X 

Report  Manual  Fault  Isolation  Measurement 

X 

SPECIAL  REQUESTS 

Request  for  Manual  Fault  Isolation  Measurement 

X 

X 

Request  to  Send  Message  to  Another  Position 

X 

X 

X 

X 

Request  to  Initialize  a Station  Position 

Request  for  Manual  Measurement 

X 

X 

Request  for  ATEC  Status 

Request  to  Initiate  Reroute  Action 

X 

X 

Request  to  Engage  a Reroute  Plan 

Request  to  Authorize  a Reroute  Action 

Request  to  Confirm  Reroute 

X 

X 

X 

Request  for  PMP/QA  Data 

X 

X 

Request  to  Issue  Fault  Status  Notification 

Request  to  Modify  Network  Configuration 

l 

X 

X 

Figure  2-4.  System  Status  Summary 


traffic  status.  In  the  case  of  AUTOVON,  whenever  a degraded  switch  or  traffic  condition 
is  reported,  the  reporting  switch  identity  and  the  report  time  will  flash  on  the  status 
monitor.  The  ACOC  controller  can  then  request  the  detailed  fault  indicator  display  at 
his  CRT  terminal.  In  the  case  of  AUTODIN  the  system  status  summary  will  comprise 
the  number  of  AUTODIN  tributaries  by  switch,  with  out  of  threshold  queues. 

2.6.2  Fault  Detail 

This  display  shall  identify  all  the  known  information  concerning  a fault.  A recom- 
mended display  layout  is  shown  in  Figure  2-5.  This  detailed  fault  information  will  be 
available  on  request  at  all  control  levels. 

2.6.3  Station  Fault  Summary 

This  display  shall  summarize  open  hazardous  condition  reports  and  other  station 
type  outages  by  station.  A recommended  display  layout  is  shown  in  Figure  2-6.  This 
information  will  be  available  on  request  at  all  control  levels. 

2.6.4  Link/Trunk/Circuit  Fault  Summaries 

These  displays  are  consolidated  summaries  of  the  information  contained  in  the 
detailed  fault  record  and  are  intended  to  list  all  links,  trunks  and  circuit  faults  by  station, 
Node,  Sector  and  ACOC,  depending  on  the  level  requesting  data.  Recommended  display 
layouts  are  shown  in  Figures  2-7  and  2-8.  These  summaries  will  be  available  on  request 
at  all  control  levels.  The  ACOC  will  encompass  summaries  of  faults  within  their 
respective  areas.  The  station  level  display  will  be  restricted  to  links,  trunks  and 
circuits  within  the  station  level  responsibility. 

2.6.5  Connectivity 

These  displays  are  intended  for  use  in  manual  fault  isolation  or  for  verification  of 
trunk  and  circuit  routing.  Figure  2-9  shows  an  example  of  a circuit  connectivity  display. 
In  this  case  the  stations,  trunks  and  channel  assignment  numbers  are  provided  to  the 
station  controller  to  identify  the  routing  and  VF  access  points  for  a particular  circuit. 


2-10 


5 


y 


H 

n 


ij_  re  2-5.  Fault  Detail 


Figure  2-7.  Link/Trunk  Fault  Summary 


If  trunk  connectivity  is  desired  the  display  will  list  the  stations  and  links  traversed 
by  the  trunk.  This  type  of  display  can  be  made  available  on  request  at  all  control 
levels.  However,  it  will  be  primarily  utilized  by  the  station  level. 

2.6.6  Switch  Equipment  Status  Summary 

These  displays  are  summaries  of  the  AUTOVON,  AUTODEN,  and  AUTOSEVOCOM 
switch  equipment  status  and  identify  those  major  equipment  items  that  have  been 
reported  in  an  out  of  service  condition.  For  example,  the  switch  equipment  status 
should  comprise  those  equipment  items  identified  in  DCAC  310-55-1.  This  information 
will  be  available  on  request  at  the  ACOC  only. 

2.6.7  AUTODIN  Traffic  Summary 

This  display  is  intended  to  alert  the  ACOC  controller  to  message  queue  buildup 
at  AUTODIN  switches.  Figure  2-10  is  an  example  of  this  type  of  display  which  includes 
the  switch  identity,  the  affected  channel  number,  the  number  of  messages  on  queue/the 
number  of  messages  for  thresholding,  and  the  date  time  group.  The  system  status 
summary  described  previously  will  automatically  indicate  an  out  of  threshold  indication 
at  the  AUTODIN  switch  to  trigger  a request  by  the  ACOC  controller  for  the  AUTODIN 
Traffic  Summary. 

2. 6. 8 AUTOVON  Switch/Traffic  Summary 

This  display  will  generally  be  used  in  conjunction  with  the  system  status  summary 
described  previously.  The  system  status  summary  will  automatically  alert  the  ACOC 
controller  to  receipt  of  trouble  indications  from  the  AUTOVON  switches.  The  ACOC 
controller  can  then  request  current  status  for  a presentation  of  the  reported  conditions. 
Figure  2-11  is  an  example  of  the  type  of  display  that  could  be  provided.  A complete  list 
of  the  indicators  for  display  at  the  ACOC  is  presented  in  Section  6. 

2.6.9  Journal  Data 

This  type  of  display  is  intended  for  selective  journal  retrieval  for  information 
concerning  such  items  as  the  types  of  actions  implemented  by  the  controllers, 
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Figure  2-10.  AUTODIN  Abnormal  Traffic  Summary 


Figure  2-11.  Example  of  AUTOVON  Summary 
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reference  of  previously  closed  fault  conditions,  and  access  to  PMP/QA  measurements. 

The  types  of  displays  will  be  dictated  by  the  specific  information  to  be  stored  in  the 
journal. 

2.6.10  Displays  for  Entering  Data 

Displays  for  entering  data  are  primarily  associated  with  the  station  level  and  are 
intended  to  simplify  the  reporting  process.  Fault  open,  update,  closure  and  HAZCON 
entry  requests  will  result  in  a display  similar  to  that  described  under  Fault  Detail 
Display  and  shown  in  Figure  2-5.  The  station  controller  will  insert  the  appropriate 
information  categories  as  required.  Displays  should  also  be  provided  for  entering 
PMP/QA  data  and  manual  fault  isolation  measurements.  In  the  latter  case  the  informa- 
tion required  is  in  response  to  an  automatic  request  from  the  node  and  comprises  a 
trunk,  or  CCSD  identifier  and  the  group  pilot  or  VF  channel  signal  level.  In  the  former 
case  the  measurement  information  required  in  support  of  the  DCS  QA  Program  DCAC 
310-70-57  will  be  inputted  to  the  node  for  inclusion  in  the  journal.  Fault  conditions 
resulting  from  such  QA  measurements  which  are  not  corrected  immediately  will  be 
entered  as  degraded  faults  in  the  fault  detail  file. 

2.G.11  Special  Request  Displays 

The  special  request  displays  are  required  in  support  of  the  major  displays  and 
cover  the  initiation  of  control  actions  such  as  directing  stations  in  manual  fault  isolation, 
directing  circuit  reroutes  and  others  as  listed  in  Table  2-1. 
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2. 7 NETWORK/TRAFFIC  FIGURES  OF  MERIT 


Figures  of  merit  provide  a valuable  tool  to  aid  a network/traffic  controller  in 
assessing  the  performance  of  his  communications  media.  Several  of  these  currently 
exist  and  are  used  on  a day  to  day  basis  to  evaluate  segments  of  the  overseas  DCS 
at  the  station  level.  These  figures  are  developed  within  the  Performance  Monitoring 
Program  (PMP)  and  include  such  daily  parameter  measurements  as  idle  channel 
noise,  receive  signal  level,  and  baseband  loading.  The  technical  control  facilities 
maintain  a continual  record  of  these  measurements  and  monitor  the  performance  of 
the  system  down  to  the  channel  level.  While  this  gives  the  technical  controller 
valuable  information  on  the  operation  of  his  equipment,  a network  controller  needs 
a more  consolidated  figure  of  merit  in  order  to  be  given  an  indication  of  the 
performance  of  the  system  within  his  area  of  responsibility. 

Several  criteria  must  be  followed  in  developing  useful  network  figures  of 
merit.  First  of  all,  the  data  required  to  produce  the  figure  of  merit  must  be  readily 
obtainable.  This  raw  data  must  also  be  trvely  indicative  of  the  condition  being 
represented.  One  of  the  more  important  considerations  is  to  be  sure  the  figure  of 
merit  can  be  utilized  by  the  network  controller.  It  must  provide  the  controller  with 
an  understandable  picture  of  the  situation  in  order  to  be  useful.  The  figure  of  merit 
should  not  be  too  complex.  That  is,  a trade-off  must  be  made  between  the  value  of 
a figure  of  merit  versus  the  quantity  of  data  and  complexity  of  computations  required 
to  arrive  at  the  figure. 

Many  of  the  figures  of  merit  developed  and  considered  for  evaluating  the 
performance  of  the  overseas  DCS  do  not  meet  one  or  more  of  the  above  criteria  and, 
therefore,  are  not  recommended.  For  example,  a figure  of  merit  based  upon  the 
throughput  of  AUTODIN  1ST' 8 would  provide  the  AUTODIN  network  controller  with  an 
excellent  tool  in  evaluating  network  traffic  backlog  conditions.  Trending  the 
throughput  of  the  IST's  would  also  help  eliminate  some  traffic  backlog  conditions  bv 
determining  a degrading  trunk  before  traffic  is  severely  affected.  This  figure  of 
merit  would  be  determined  by  a ratio  of  the  number  of  NAK's  received  by  a switch 
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and  the  total  number  of  transmissions  made  for  a given  trunk.  However,  the  NAK 
rates  for  the  AUTO  DIN  switches  are  not  currently  accessible,  so  this  figure  of  merit 
cannot  be  calculated  at  the  present  time. 


11 


I 


f " 


[j 

0 

2 

I 


Those  figures  of  merit  that  have  been  developed  and  are  considered  feasible  to 
obtain  and  useful  to  the  network  controllers  are  described  in  the  following  paragraphs. 

2.7.1  Call  Processing  Efficiency 

This  figure  of  merit  provides  the  AUTOVON  network  controller  with  a single 
percentage  figure  that  summarizes  the  current  performance  of  a switch  within  the 
network.  The  percentage  of  call  processing  efficiency  is  computed  by  taking  the  ratio 
of  the  number  of  calls  which  the  switch  successfully  completed  and  the  number  of  calls 
which  were  attempted.  This  figure  accurately  reflects  the  effectiveness  of  the  switch 
in  successfully  processing  traffic. 

2. 7. 2 Fault  Severity 

An  indication  of  fault  severity  is  derived  from  the  fault  assessment  function 
that  is  performed  at  the  node.  This  figure  of  merit  summarizes  the  extent  to  which 
any  one  fault  degrades  the  performance  of  the  network.  It  is  of  particular  use  at  the 
sector  level  in  evaluating  the  need  for  establishing  a reroute.  The  factors  involved  in 
determining  this  figure  are  the  level  of  the  fault  (link,  trunk,  or  circuit),  the  degree 
of  degradation  (out  or  degraded),  priority,  and  estimated  time  to  restore. 

2.7.3  Network  Availability 

The  purpose  of  this  figure  of  merit  is  to  ascertain  the  portion  of  the  network 
that  is  available  for  use.  This  figure  provides  a network  controller  with  a summary 
identifying  what  portion  of  the  network  is  operational  at  any  time.  Calculating  this 
figure  involves  combining  the  Fault  Severity  figures  of  merit  to  determine  the  degree 
of  degradation  of  performance  within  the  network. 

i 

Each  Fault  Severity  figure  of  merit  for  the  portion  of  the  network  being  examined 
(node,  sector,  or  theater)  must  be  reduced  to  the  total  number  of  circuits  being 
affected.  For  example,  a Fault  Severity  of  a trunk  being  carried  in  an  outage  condition 
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would  be  counted  as  twelve  circuits  in  an  outage  condition.  The  number  of  circuit 
outages  and  degraded  circuits  are  then  totaled  by  priorities.  Next,  each  circuit 
total  is  weighted  by  the  factors  shown  below: 

Weighting  Factor 

Circuit  Priority  Outage  Degradation 

1 10  5 

Other  2 1 

The  weighted  totals  are  now  added  and  the  sum  is  the  adjusted  figure  representing 
the  effective  degree  of  circuit  degradation.  This  number  is  then  subtracted  from 
the  total  number  of  circuits  within  the  portion  of  the  network  being  analyzed,  the 
percentage  of  circuits  remaining  being  the  figure  of  merit. 

Take,  for  example,  a theater  level  analysis  within  Europe.  Assume  at  the 
time  of  request  the  distribution  of  degradations  of  a link  outage  consisting  of  50 
priority  1 circuits  and  130  of  lesser  priority,  3 trunk  outages  consisting  of  8 priority 
1 circuits  and  28  of  lesser  priority,  18  circuit  outages  consisting  of  3 priority  1 and 
15  lower  priority  circuits,  and  26  degraded  circuits  of  lesser  priority.  The  circuit 
totals  are  shown  below: 


Circuit  Priority 

Totals 

Outage 

Degradation 

1 

61 

0 

Other 

173 

26 

Multiplying  these  totals  by  the  weighting  factors  and  adding  results  in  a weighted 
degradation  of  982.  Subtracting  from  a total  number  of  actual  circuits  of  approxi- 
mately 10,  200  arrives  at  a total  of  9218,  making  the  figure  of  merit  for  these 
conditions  92  percent.  This  percentage  will  give  the  network  controller  a single 
figure  summary  of  the  relative  condition  of  the  network. 

This  figure  of  merit  can  be  calculated  for  different  levels  of  the  unified 
control  hierarchy.  Each  nodal,  sector,  or  network  controller  can  be  given  a figure 
for  his  area  of  responsibility.  The  network  controller  at  the  ACOC  could  be  given 
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a theater  figure  of  merit,  as  well  as  figures  by  sector  and  node.  The  controller 
could  then  determine  the  degraded  areas  of  the  system  when  network  availability  is 
down. 
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2.7.4  Congestion 


An  indication  of  traffic  congestion  within  the  AUTODIN  network  is  determined  by 
thresholding  message  queue  lengths  on  the  switch  traffic  summaries.  Any  channel 
with  an  exceeded  threshold  will  be  examined  for  any  degraded  indications  within  the 
control  structure.  This  information  is  compared  to  determine  if  the  excessive  queue 
is  because  of  a heavy  volume  of  traffic  or  possibly  because  of  difficulty  in  the  circuit. 
This  figure  of  merit  can  assist  the  AUTODIN  controller  in  identifying  choke  points 
within  the  AUTODIN  system. 


2.7.5  Percent  Trunk  Utilization 

Percent  trunk  utilization  on  AUTOVON  trunk  groups  will  provide  the  traffic 
distribution  and  choke  point  identification  for  the  AUTOVON  network.  Data  from  each 
of  the  AUTOVON  switches  is  collected  and  the  percent  of  usage  by  trunk  group  is 
calculated.  This  figure  of  merit  also  assists  the  AUTOVON  controller  in  making 
traffic  control  decisions  during  periods  of  excessive  traffic  loading  within  the  network. 
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SECTION  3 - NODE  REQUIREMENTS 


3. 1 FUNCTIONAL  DESCRIPTION 


This  functional  description  encompasses  the  functions  performed  at  the  nodal 
level  of  the  Unified  Control  System.  Functions  performed  at  each  of  the  different  types 
of  stations  which  are  the  sources  of  information  for  the  nodes  are  also  outlined. 


In  the  detailed  flowcharts  that  follow  many  connections  between  pages  were 
required  because  of  the  complexity  of  the  diagrams.  A continuation  to  or  from  a 
different  page  is  shown  by  a circle  with  a number  in  it.  The  numbering  system  is  the 
same  as  that  used  on  the  general  flowchart  . If  a circle  contains  N3-1  the  flow  con- 
tinues on  Sheet  3 of  the  nodal  level  flowchart,  the  second  number  distinguishing  different 
inputs  on  the  same  page.  A single  circle  indicates  the  flow  is  information  only,  and  two 
concentric  circles  indicate  that  the  flow  is  control  and  direction  as  well  as  information. 


The  majority  of  the  functions  illustrated  within  the  nodal  level  are  envisioned  as 
being  automatically  processed.  At  several  points,  however,  operator  intervention  is 
required.  This  is  indicated  within  the  flowcharts  by  the  dashed  lines,  unless  otherwise 
noted. 

3.1.1  Station  Level  Functions 

Figure  3.1-1  is  a series  of  flowcharts  illustrating  the  functions  performed  at  each 
type  of  reporting  station. 

3. 1. 1. 1 TCF  Station  Flowchart 

Sheet  1 shows  the  flowchart  for  a manual  TCF  station.  The  function  depicted  on 
this  chart  will  all  be  performed  by  the  technical  controllers  within  the  facility  . 

The  controller  will  be  aware  of  the  status  within  the  station  by  way  of  user  complaints, 
local  equipment  alarms,  and  manual  monitoring  and  testing.  The  controller  must  assess 
the  condition  of  any  problem  that  arises  (b)  . If  he  determines  a hazardous  condition 
exists,  it  will  be  reported  to  the  node  as  such  (c)  . If  a link,  trunk,  or  circuit  problem 
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Figure  3.1-1.  Station  Level  Functional  Flowchart  (Sheet  1 of  6)  TCF 
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exists  the  controller  must  make  the  determination  if  the  problem  is  within  the  station  (5^. 
If  it  is,  he  will  isolate  the  fault  , report  it  to  the  node  as  a station  problem  (f^)  , 
and  initiate  restoral  actions  0- 

If  the  problem  is  not  within  the  station  and  it  is  a link  or  trunk  problem  , 
controller  must  determine  whether  to  report  it  to  the  node  as  a degradation  or  an 
outage  Q . If  it  is  a circuit  problem  and  the  circuit  terminates  at  the  station,  the 
controller  must  determine  if  user  service  is  affected  (j)  . If  it  is,  the  problem  is 
reported  as  an  outage  . If  not,  or  if  the  circuit  does  not  terminate  at  the  station, 
the  problem  is  reported  as  a degradation  , 

The  node  will  at  times  request  the  technical  controller  to  make  a level  check  on 
a circuit  or  a group  pilot  checV  on  a trunk  to  support  the  nodal  fault  isolation  . 

The  controller  will  send  the  results  back  to  the  node  . The  node  can  also  instruct 
the  controller  to  implement  a reroute  . After  the  reroute  is  established,  the 
controller  must  send  an  update  report  to  the  node  . 

The  technical  controller  also  performs  quality  assurance  testing  (o)  . These 
measurements  are  sent  to  the  node  which  forwards  them  to  the  sector  where  they  are 
journaled  for  access  at  a later  time. 

3. 1. 1. 2 ETC  Station  Flowchart 

Sheet  2 is  the  flowchart  for  a satellite  earth  terminal  complex.  Again,  all  the 
functions  shown  will  be  performed  by  the  controllers  within  the  facility  ^A^  . Status 
within  the  station  will  be  derived  from  local  equipment  alarms,  satellite  link  status, 
and  monitoring  and  testing.  The  earth  terminal  controller  will  assess  any  link,  trunk, 
or  circuit  problems  (b)  and  determine  if  the  problem  is  within  the  satellite  system 

. If  it  is,  the  controller  will  initiate  fault  isolation  and  report  the  problem 
to  the  node  as  fault  isolated  to  the  satellite  system.  If  the  problem  is  not  within  the 
satellite  system  the  controller  will  report  the  fault  as  an  outage  or  a degradation 
to  the  node  . The  node  can  also  request  the  earth  terminal  controller  to  input 
information  in  support  of  fault  isolation  . 
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3. 1. 1. 3 AUTODIN  Station  Flowcharts 
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Sheet  3 shows  the  transmission  oriented  information  flow  at  AUTODIN  switch 
stations.  AUTODIN  switch  alarm  points  are  automatically  scanned  and  initiate 
"U"  line  report  preparation  within  the  processor  . Upon  generation  of  a report  a 
request  is  printed  out  to  the  PTF  for  an  RFO  code  . The  AUTODIN  personnel 
must  then  determine  if  it  is  a switch  equipment  problem  or  a problem  outside  of  the 
switch  station  (d^,  and  input  the  appropriate  RFO  code  ^E^F^ . Upon  reoeipt  of  the 
RFO  code  or  after  4 minutes,  whichever  comes  first,  the  report  will  be  sent  off  to  the 
node  ((^  . 

The  node  will  send  information  to  the  station  regarding  the  status  of  AUTO  DIN 
circuits  and  make  requests  of  the  AUTO  DIN  controller  for  information  (h^  . The 
controller  can  manually  input  status  to  the  node(T^,  and  will  return  level  measurements 
when  requested  by  the  node  to  support  fault  isolation  (?)  . 

Sheet  4 of  the  station  level  flowcharts  illustrates  the  functional  flow  of  AUTODIN 
station  traffic  monitoring.  The  switch  personnel  take  traffic  STAT's  periodically  to 
monitor  the  traffic  within  the  switch  (a)  . The  traffic  data  is  periodically  sent  to  the 
ACOC  © , although  not  as  often  as  it  is  reviewed  at  the  station.  The  switch  operators 
examine  the  queues  built  up  within  the  switch  to  determine  if  they  are  all  within  threshold 
© . if  they  are  not,  or  if  a threshold  is  being  approached,  the  operator  must  establish 
if  the  condition  has  been  previously  reported  . If  it  has  not,  the  operator  will  inform 
the  ACOC  of  the  backlog  condition  (e)  and  send  the  current  traffic  status  immediately 
and  eac  < time  the  station  takes  them  (?)  . The  switch  personnel  will  then  determine 
appropriate  control  actions  (g)  , utilizing  circuit  status  information  provided  by  the 
node  and  local  alarms  at  the  switch  The  ACOC  must  be  notified  of  the  intended 

actions  and  will  verify  them  and/or  instruct  the  switch  operator  to  implement  other 
controls  (l^. 

The  station  personnel  will  continue  to  monitor  the  traffic.  If  the  condition  is 
stabilizing  or  improving  no  further  action  is  required  until  the  condition  is  cleared 

enough  to  remove  the  controls.  If  the  condition  is  still  degrading  , the  control 
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Figure  3.1-1.  Station  Level  Functional  Flowchart  (Sheet  3 of  6)  AUTODIN 
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actions  are  reevaluated  (g)  . Once  all  the  parameters  return  to  within  threshold 
the  reports  to  the  ACOC  should  revert  to  the  normal  time  period  (m)  . The  local  switch 
alarms  that  are  not  directly  related  to  access  lines  or  ET's  are  also  sent  to  the  ACOC  by 
the  station  personnel  . 

3. 1. 1. 4 AUTOVON  Station  Flowchart 

Sheet  5 is  the  flowchart  for  an  AUTOVON  switch  station.  Data  from  the  diagnostic 
processor  , AUTOVON  switch  register  memory  (b)  , line/trunk  status  (c)  , and 
switch  equipment  status  © are  correlated  to  evaluate  the  call  processing  status  within 
the  switch  . This  information  is  also  compared  with  additional  data  concerning  line 
termination  troubles  from  the  diagnostic  processor  . This  process  will  determine 
circuit  problems  on  AUTOVON  ET's  or  access  lines  and  will  forward  the  information  to 
the  node  ^3^  for  entry  into  the  system  as  a circuit  fault.  If  the  AUTOVON  circuit  has 
been  designated  as  a special  interest  circuit,  the  ACOC  AUTOVON  controller  will  be 
notified  and  presented  the  information  about  the  problem. 

Other  call  processing  data  is  evaluated  © to  determine  if  traffic  processing  is 
being  affected  . If  it  is  not,  the  call  processing  information  is  stored  within  the 
station  level  data  base  and  sent  to  the  ACOC  only  if  requested  . If  call 
processing  is  being  affected  , the  ACOC  is  notified  of  the  condition  and  is  sent 
information  concerning  the  source  of  the  problem  If  it  is  call  processing  efficiency 

that  is  degraded,  the  information  will  be  displayed  to  the  station  personnel  . 

The  node  will  send  information  to  the  station  concerning  the  status  of  AUTOVON 
circuits  and  make  requests  of  the  PTF  controller  for  information  The  controller 

can  manually  input  data  to  the  node,  as  well  as  make  requests  for  information  (n^  . 

The  controller  will  also  return  level  measurements  when  requested  by  the  node  in  support 
of  fault  isolation(o). 

3. 1. 1. 5 AUTOSEVOCOM  Station  Flowchart 

Sheet  6 is  the  functional  flowchart  for  an  AUTOSEVOCOM  station.  This  station, 
like  the  TCF  and  ETC  stations,  provides  manual  inputs  with  the  PTF  controller  per- 
forming the  functions  illustrated  . The  sources  of  information  available  to  the 
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Figure  3.1-1.  Station  Level  Functional  Flowchart  (Sheet  6 of  6)  AUTOSEVOCOM 
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controller  are  user  complaints,  trunk  and  narrow  band  access  line  equipment  alarms, 
and  AUTOSEVOCOM  switch  alarms.  If  upon  assessing  the  condition  of  the  station  , 
the  controller  determines  a hazardous  condition  exists,  he  will  report  it  to  the  node^D^ . 
If  there  is  a trunk  or  narrow  band  access  line  problem,  the  controller  must  determine  if 
the  trouble  is  located  within  the  station  (e^  . If  not,  the  fault  is  reported  to  the  node 
as  an  outage  or  a degraded  condition  . 

If  there  is  a problem  within  the  station  involved  with  the  switch  or  a user  O’ 
the  PTF  controller  will  initiate  fault  isolation  actions  , and  send  the  information 
to  the  ACOC  © . If  there  is  a trunk  or  narrow  band  access  line  problem  that  is 
within  the  station  ©©  , the  controller  will  initiate  fault  isolation  and  inform 
the  node  that  there  is  a problem  that  has  been  isolated  to  the  station  . The  node 
can  also  request  the  PTF  controller  to  input  information  in  support  of  fault  isolation  (c^. 

3.1.2  Nodal  Level  Functions 

Figure  3. 1-2  is  the  functional  flowchart  for  the  node.  Sheet  1 shows  the  inputs 
originating  at  satellite  earth  terminal  complexes,  AUTOVON,  AUTOSEVOCOM, 
AUTODIN,  and  manual  TCF  stations.  The  node  initially  examines  the  inputs  to  deter- 
mine what  type  of  information  is  being  reported  from  the  stations.  First,  if  the 
information  concerns  a newly  discovered  fault  the  fault  assessment  routine 

(Sheet  3)  at  the  node  is  initiated.  If  not,  the  node  determines  if  the  station  is  updating 
the  status  of  a previously  reported  trouble.  In  the  case  when  the  station  is  reporting 
that  an  outage  has  been  rectified  and  the  situation  is  back  to  normal  ^b)  , the  node  will 
journal  the  fault  detail  record  associated  with  that  outage  (d)  . The  node  will  also 
inform  all  TCF's  that  originally  reported  the  problem  that  the  problem  is  now 
corrected.  The  fault  will  then  be  deleted  from  the  data  base  (e^  , and  the  informa- 
tion will  be  forwarded  to  the  sector  (?)  . If  the  report  is  just  updating  the  status  of 
a current  outage  (c)  , the  node  will  update  the  information  within  the  data  base  (js) 
and  send  the  information  to  the  sector.  Each  time  the  data  base  is  updated  nodes 
which  have  an  AUTOVON  or  AUTODIN  switch  within  their  areas  will  enter  the  routine 
on  Sheet  4 to  distribute  circuit  status  to  the  appropriate  switch  status. 
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Figure  3. 1-2.  Nodal  Level  Functional  Flowchart  (Sheet  1 of  7) 
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If  the  report  is  concerning  a hazardous  condition  at  a station  ((T)  , the  node  will 
store  the  information  within  its  data  base  and  forward  the  information  to  the  sector 
. The  nodal  controller  will  be  kept  informed  of  HAZCON's  within  his  nodal  area  by 
receiving  displays  of  the  information  as  it  is  reported  . 

The  node  will  also  receive  quality  assurance  measurements  made  at  the  stations 
. These  measurements  will  not  be  acted  on  by  the  node,  but  will  be  forwarded  to 
the  sector  for  journaling 

Sheet  2 shows  the  inputs  originating  at  ATEC  equipped  stations.  The  ATEC 
measurement  acquisition  and  fault  isolation  algorithms  will  operate  independently 
from  the  unified  system  control  information  flow,  as  discussed  in  Section  2 , with 
the  interface  being  the  status  information  exchange.  When  an  alarm  condition  is 
received  from  a station  measurement  acquisition  subsystem  (MAS)  at  the  nodal  control 
subsystem  (NCS)  , the  NCS  will  first  check  the  nodal  data  base  to  see  if  there  is 
a fault  isolated  report  related  to  the  problem  that  has  been  detected  by  the  MAS  . 

For  example,  if  the  MAS  discovers  a circuit  problem,  the  nodal  data  base  may  already 
contain  the  information  that  the  circuit  is  out  because  of  a trunk  problem  in  another 
part  of  the  system.  If  there  is  no  related  report  ATEC  will  proceed  with  its  fault 
isolation  process  and  the  nodal  data  base  will  be  updated  to  include  the  fault  . 

If  the  fault  has  already  been  isolated,  ATEC  will  cancel  its  fault  isolation  routine  . 

Sheet  3 of  the  functional  flowchart  shows  the  performance  assessment  that  is  done 
within  the  node.  This  routine  is  entered  from  Sheet  1 for  all  newly  reported  faults  from 
stations  within  the  nodal  area  with  the  exception  of  ATEC  detected  faults.  The  node  will 
first  look  to  see  if  the  fault  is  isolated;  that  is,  the  station  is  reporting  a fault  and  has 
already  determined  the  reason  for  outage  ^A^ . If  this  is  the  case  then  the  information 
updates  the  data  base  , and  the  information  distribution  routine  on  Sheet  4 is  entered 
if  an  AUTODIN  or  AUTOVON  switch  is  within  the  nodal  area.  The  node  will  then  deter- 
mine if  it  is  currently  processing  any  related  outages  or  degradations  , and  if  so, 
cancel  the  fault  isolation  that  is  in  progress  . In  either  case,  the  information  will 
be  sent  to  the  sector  . 
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Figure  3. 1-2.  Nodal  Level  Functional  Flowchart  (Sheet  3 of  7) 
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If  the  fault  is  not  isolated  ® , the  data  base  is  examined  to  determine  if  any 
associated  outages  have  been  reported  This  could  be  an  equal  level  problem  that 

was  reported  earlier  by  a different  station,  or  a higher  order  problem,  perhaps  from 
a different  part  of  the  network,  that  is  causing  the  reported  fault.  If  an  associated 
problem  has  been  reported,  the  fault  isolation  procedure  will  already  be  in  progress. 
Therefore,  the  fact  that  the  station  reported  the  trouble  is  stored  (JT)  , in  order  that 
the  node  can  inform  the  station  when  the  problem  is  resolved.  The  station  is  also 
informed  at  the  time  of  reporting  about  the  associated  fault  and  that  fault  isolation  is 
in  progress  . Any  additional  detailed  information  will  also  be  forwarded  to  the 
sector.  If  the  responsible  station  is  located  within  a different  nodal  area,  the  sector 
will  forward  the  information  to  the  other  nodal  area  as  an  assistance  in  isolating  the 
problem. 

If  no  associated  outages  have  been  reported  , and  the  report  is  a degraded 
condition  , then  the  data  base  is  checked  to  see  if  any  associated  degradations 
have  been  reported  If  there  have  been  then  the  report  is  handled  as  through  an 

associated  outage  had  been  reported.  If  not,  the  appropriate  information  (as  described 
previously)  is  sent  to  the  sector  (7)  and  the  fault  isolation  routine  on  Sheet  4 is 
initiated. 

If  the  newly  reported  fault  is  an  outage  , then  the  node  will  examine  the  data 
base  to  see  if  any  higher  level  degradations  have  been  reported  (l)  . That  is,  if  the 
report  is  on  a trunk,  check  for  any  degraded  links  which  the  trunk  goes  over,  or  if  the 
report  is  on  a circuit  check  for  degraded  indications  on  any  trunk  or  link  which  the 
circuit  traverses.  If  there  are  no  such  indications,  then  the  appropriate  information  is 
sent  to  the  sector  and  the  fault  isolation  routine  on  Sheet  4 is  initiated.  If  a higher 
order  degradation  has  been  reported  , the  information  on  the  outage  and  degradation 
is  displayed  to  the  nodal  controller  © who  must  decide  if  the  outage  condition  has  most 
likely  been  caused  by  the  degraded  link  or  trunk  . If  the  controller  determines  the 
problems  are  related,  the  report  is  stored  so  the  station  can  be  informed  when  the  fault 
is  corrected  © . The  station  is  also  immediately  informed  of  the  higher  order  trouble 
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and  that  work  is  in  progress  . If  the  controller  decides  the  outage  is  not  related 
to  the  higher  order  degradation,  the  information  is  sent  to  the  sector  (T)  as  a new 
fault  and  the  nodal  fault  isolation  routine  is  started. 

Sheet  4 shows  the  information  distribution  to  AUTODIN  and  AUTOVON  switch 
stations  as  well  as  the  initial  steps  of  the  fault  isolation  routine.  New  fault  information, 
entering  this  routine  at  N4-1,  is  first  entered  into  the  nodal  data  base  . If  the 
station  designated  as  being  responsible  for  manual  fault  isolation,  if  required,  is  within 
this  nodal  area,  all  of  the  detailed  fault  information  is  stored.  If  the  responsible  station 
is  not  within  this  nodal  area,  only  a summary  of  the  fault  is  maintained;  the  detailed 
information  having  been  forwarded  to  the  appropriate  node  via  the  sector. 

Those  nodes  which  have  an  AUTODIN  switch  within  their  area  check  the  new 
reports,  as  well  as  all  other  new  and  update  information  from  the  sector,  stations,  or 
ATEC  (entering  at  N4-2),  to  see  if  an  AUTODIN  circuit  is  affected  (eT)  . If  so,  the 
node  will  display  the  information  on  the  degraded  circuit  to  the  AUTODIN  switch  station 
personnel  © , as  described  earlier  in  the  station  descriptions.  Likewise,  nodes 
which  have  an  AUTOVON  switch  within  their  area  will  check  all  new  and  update  informa- 
tion for  an  affected  AUTOVON  circuit  ©.  When  a circuit  is  affected,  the  information 
will  be  sent  to  the  AUTOVON  station  for  display  to  the  station  personnel  ( £ ) . 

The  newly  reported  problems  from  the  sa  tellite  earth  terminal  complexes, 
AUTOVON,  AUTOSEVOCOM,  AUTODIN,  and  manual  TCF  stations  also  initiate  the 
fault  isolation  routine.  If  the  reported  fault  is  on  a link  , the  node  checks  to  see 
if  the  link  is  equipped  with  ATEC  © . If  so,  ATEC  is  requested  to  make  an  immediate 
monitor  on  the  link  (7^  and  will  communicate  with  the  stations  through  its  own  routines. 
If  the  link  is  not  equipped  with  ATEC,  the  node  will  pass  the  information  it  has  on  the 
problem  to  the  stations  (or  station  if  the  link  crosses  the  nodal  boundary)  which 
terminate  the  link  and  instruct  them  to  coordinate  and  fault  isolate  the  problem  ©• 

If  the  reported  fault  is  not  on  a link  © , and  is  on  a trunk  (7)  , then  the  trunk 
fault  isolation  routine  on  Sheet  5 is  initiated.  If  the  problem  is  not  on  a trunk,  then  the 
node  proceeds  to  the  circuit  routine  on  Sheet  6. 
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Figure  3.1-2.  Nodal  Level  Functional  Flowchart  (Sheet  4 of  7) 


Sheet  5 shows  the  fault  isolation  algorithm  at  the  node  for  trunk  related  problems. 
The  first  action  taken  by  the  node  is  to  check  to  see  if  the  trunk  is  equipped  to  be 
monitored  by  A TEC  . If  not,  the  data  base  is  examined  to  determine  if  the  trunk 

is  contained  completely  within  the  nodal  area  (b)  . If  it  is  not,  the  node  will  wait  for 
a command  from  the  sector  to  proceed  (c^  . This  pause  is  to  allow  the  sector  to 
check  the  other  nodes  involved  to  see  if  any  are  equipped  with  ATEC  to  monitor  the 
trunk.  If  so,  the  sector  will  wait  for  the  results  from  ATEC  before  commanding  the 
nodes  to  initiate  the  manual  fault  isolation.  This  will  utilize  the  capabilities  of  ATEC 
to  rapidly  perform  measurements,  which  will  reduce  and  possibly  eliminate,  depending 
upon  the  location  of  the  fault,  the  amount  of  unnecessary  manual  fault  isolation  performed. 

If  the  trunk  is  contained  within  the  nodal  area  ® , or  the  node  has  been  told  to 
proceed  by  the  sector  (c^)  , the  node  will  instruct  each  station  which  the  trunk  passes 
through  to  make  a group  pilot  check  . This  information  will  be  entered  by  the 
station  personnel  stored  in  the  data  base  and  displayed  to  the  nodal  controller 
The  controller  will  review  the  information  to  determine  if  any  problem  was  revealed  by 
the  group  pilot  measurements  . If  so,  but  the  problem  appears  to  be  entering  from 
an  adjacent  node  ^T)  , the  information  on  the  abnormality  found  will  be  sent  to  the 
sector  0.  If  the  problem  is  within  the  nodal  area  , the  stations  involved  are 
given  information  about  the  fault  by  the  node  and  instructed  to  proceed  with  fault  isolation 
. The  sector  is  also  informed  that  the  problem  has  been  isolated  to  this  nodal  area 
(JT).  This  allows  the  sector  to  stop  all  other  fault  isolation  in  progress  within  other 
nodal  areas.  The  sector  may  also  direct  the  node  to  instruct  a station  at  the  nodal 
boundary  to  coordinate  with  the  boundary  station  of  another  node  when  the  sector  deter- 
mines the  problem  is  between  the  two  nodal  areas  . 

If  the  nodal  controller  determines  that  the  group  pilot  level  with  his  nodal  is 
normal  © , the  sector  is  informed  that  no  problem  was  found  . If  the  station 
responsible  for  manual  fault  isolation  is  not  within  the  nodal  area  © , the  node 
maintains  the  information  on  the  trunk  , and  takes  no  further  action  unless  directed 
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Figure  3. 1-2.  Nodal  Level  Functional  Flowchart  (Sheet  5 of  7) 
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to  by  the  sector.  If  the  responsible  station  is  within  the  nodal  area  , and  the 
trunk  leaves  the  nodal  area,  the  node  will  again  wait  for  an  indication  to  proceed  from 
the  sector  (p)  , which  is  examining  the  results  from  other  nodal  areas.  Once  the 
node  receives  the  indication  to  proceed  or  if  the  trunk  is  contained  within  the  nodd 
area,  and  the  problem  is  an  outage  , the  node  will  give  the  responsible  station  the 
routing  of  the  trunk  and  instruct  the  personnel  to  initiate  manual  fault  isolation  (r)  . 

If  the  problem  has  been  reported  as  a degradation  , all  the  information  available 
is  displayed  to  the  nodal  controller  who  must  decide  if  the  condition  is  severe 
enough  to  warrant  further  investigation  . 

If  the  trunk  is  equipped  to  be  monitored  by  ATEC  (a)  , the  node  will  request  a 
immediate  monitor  . If  ATEC  reveals  a problem  , this  routine  stops  and  the 
ATEC  system  will  proceed  and  inform  the  controller  of  the  results.  If  ATEC  does  not 
reveal  a problem  , the  routine  proceeds  in  the  same  manner  as  if  no  problems 


were  found  with  the  manual  level  checks. 


Sheet  6 shows  the  fault  isolation  algorithm  for  circuit  related  problems.  The  node 
first  checks  to  see  if  the  circuit  is  equipped  to  be  monitored  by  ATEC  . If  it  is  not, 
the  data  base  is  examined  to  determine  if  the  path  of  the  circuit  is  contained  within  the 
nodal  area  . If  not,  the  node  will  wait  for  a command  from  the  sector  to  proceed 
. This  pause  is  to  allow  the  sector  to  check  the  other  nodes  involved  to  see  if  they 
are  equipped  with  ATEC,  and  if  so  to  check  them  first. 


If  the  circuit  is  contained  within  the  nodal  area,  the  database  is  examined  to 
determine  if  the  circuit  has  a level  to  monitor  . If  so,  or  if  the  circuit  leaves  the 
nodal  area  and  the  sector  directs  the  node  to  proceed,  the  node  will  request  a level 
monitor  from  each  station  which  the  circuit  passes  through  . The  measurements 
will  be  entered  by  the  station  personnel,  stored  in  the  data  base  , and  displayed  to 
the  nodal  controller  . The  controller  will  review  the  information  to  determine  if 
any  level  problems  are  revealed  . If  so,  but  the  problem  is  entering  from  another 
nodal  area  , the  information  found  is  sent  to  the  sector.  If  the  problem  is  within 


the  nodal  area,  the  stations  involved  are  given  the  information  on  the  fault  and  instructed 
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Figure  3.1-2.  Nodal  Level  Functional  Flowchart  (Sheet  6 of  7) 
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to  proceed  with  fault  isolation  The  sector  is  also  informed  that  the  problem  is 

within  this  nodal  area  (T)  so  the  sector  can  cancel  other  fault  isolation  in  progress. 

The  sector  can  also  direct  the  node  to  have  a station  on  the  nodal  boundary  coordinate 
with  a station  in  an  adjacent  nodal  area  to  fault  isolate  troubles  across  the  nodal 
boundary  . 

If  the  nodal  controller  determines  that  nothing  is  revealed  by  the  level  checks 

the  sector  is  informed  that  no  problem  was  found  . If  the  station  responsible 
for  manual  fault  isolation  is  not  within  the  nodal  area  , the  node  will  store  the  in- 
formation on  the  fault  , but  will  take  no  further  action  unless  instructed  by  the 
sector.  If  the  responsible  station  is  within  the  nodal  area,  and  the  circuit  leaves  the 
nodal  area,  the  node  will  wait  for  direction  from  the  sector  to  proceed  . This  pause 
is  to  allow  the  sector  to  examine  the  results  from  other  nodal  areas.  If  the  circuit  is 
contained  within  the  nodal  area,  the  node  has  been  given  the  indication  to  proceed,  or 
the  circuit  has  no  level  to  monitor  , the  node  will  check  to  see  if  the  report  was 
an  outage  or  a degraded  condition.  If  it  is  an  outage,  the  node  will  give  the  responsible 
station  the  routing  of  the  circuit  and  instruct  the  personnel  to  begin  manual  fault  isolation 
© . If  the  problem  has  been  reported  as  a degradation  (^»  all  the  information 
available  is  displayed  to  the  nodal  controller  ^t)  . The  controller  must  assess  the 
severity  of  the  degradation  and  determine  if  a request  should  be  made  to  take  the  circuit 
out  of  service  for  further  testing  (u)  . 

If  the  circuit  is  equipped  to  be  monitored  by  ATEC  , the  node  will  request 
an  immediate  monitor  on  the  circuit  . If  ATEC  reveals  a problem  , this 
routine  stops  and  the  ATEC  system  will  inform  the  controller  of  the  results.  If  ATEC 
does  not  reveal  a problem  (m)  , the  routine  continues  in  the  same  manner  as  if  no 
problem  was  found  with  manual  level  measurements. 

Sheet  7 shows  the  information  and  direction  received  at  the  node  from  the  sector 
© . The  node  first  checks  to  see  if  the  information  concerns  a new  fault  or  a fault 
which  is  currently  being  processed  at  the  node  so,  and  the  information 

indicates  that  the  problem  has  already  been  fault  isolated  , the  node  checks  to  see 
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Figure  3. 1-2.  Nodal  Level  Functional  Flowchart  (Sheet  7 of  7) 
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if  it  is  currently  working  on  any  associated  problems  (d)  . If  so,  the  fault  isolation 
is  stopped  and  the  information  is  maintained  in  the  data  base  until  the  fault  is  cleared 
. If  the  node  has  an  AUTODIN  or  AUTOVON  switch  within  its  area,  the  routine 
goes  on  to  Sheet  4 to  distribute  the  status  information  to  the  switch  stations  or  the 
appropriate  circuits.  If  the  information  concerns  a new  outage  or  degraded  condition 
© , the  fault  isolation  routine  on  Sheet  4 is  initiated. 

If  the  information  is  not  on  a new  or  current  fault  , the  node  checks  to  see  if 
it  is  an  update  or  closure  of  a problem  previously  processed  and  currently  being  worked 
on  at  the  station  level  . If  it  is,  the  node  updates  the  status  within  its  data  base^^. 
The  information  distribution  routine  on  Sheet  4 is  again  entered  if  the  node  has  an 
AUTODIN  or  AUTOVON  switch.  The  journaling  function  for  closures  is  performed  by 
the  nodal  area  containing  the  station  responsible  for  the  manual  fault  isolation  and  is 
not  performed  here  to  eliminate  duplication. 

If  the  information  is  not  an  update  , it  is  information  about  a reroute  action 
being  implemented  by  the  sector  . The  node  updates  its  data  base  to  indicate  the 
reroute  plan  is  being  implemented  and  checks  to  see  if  either  terminal  TCF  for 

the  trunk  or  circuit  is  within  its  nodal  area  . If  not,  no  further  action  is  required 
of  this  node.  If  one  or  both  of  the  terminal  TCF's  are  within  the  nodal  area,  the  node 
will  direct  the  TCF(s)  to  coordinate  on  the  implementation  of  the  reroute  . Upon 
implementing  the  reroute  one  TCF  will  send  an  update  report  to  its  node  indicating  that 
the  reroute  is  established. 
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3 . 2 NODE  DATA  BASE  DESCRIPTION 


The  following  paragraphs  describe  the  nodal  level  data  base  in  terms  of  its 
structure,  content  and  sizing  requirements. 

3.2.1  Structure 

In  support  of  the  unified  control  effort  at  the  node,  nine  data  files  were  created. 

These  files  include  node,  station,  link,  trunk  and  CCSD  masters,  a measurement 
detail,  fault  detail,  and  a related  fault  detail.  Figure  4. 2-1  pictures  graphically 
the  data  base  structure.  The  linkages  between  data  sets  indicate  that  the  detail 
data  set  records  can  be  accessed  through  master  record  pointers.  In  this  case, 
a chain  of  fault  detail  records  can  be  retrieved  for  each  node,  responsible  station, 
link,  trunk,  CCSD  or  fault  ID,  hi  addition,  chains  of  related  fault  records  can  be 
read  for  each  fault  ID  and  a chain  of  measurement  data  records  can  be  read  for 
each  CCSD  or  trunk. 

3 . 2.2  Content 

Tables  4.2-1  through  4.2-9  describe  the  content  and  format  of  each  data  file 
within  the  nodal  level  data  base. 

The  connectivity  for  each  station,  link,  trunk  and  circuit  within  the  nodal  area 
is  provided  in  each  of  the  respective  master  data  files.  A status  summary  or  "degree 
of  degradation"  is  also  provided  in  these  files.  As  faults  are  reported  to  the  system, 
these  status  files  are  updated  at  every  node  containing  the  station  link,  trunk  or  circuit 
master  record.  The  detailed  fault  record,  generated  from  a trouble  report,  is  added 
to  the  nodal  data  base  of  the  responsible  station.  Any  additional  trouble  reports  on  the 
same  problem  will  cause  related  fault  file  records  to  be  added  to  the  data  base  and 
linked  to  the  detailed  fault  record.  rj 

L) 

In  the  process  of  fault  isolation,  group  pilot  and  channel  level  measurements 
will  be  made  where  possible.  A separate  file  which  is  keyed  on  trunk  or  CCSD  number 

1 4 

has  been  set  up  to  save  the  readings  as  they  come  back  from  the  stations. 
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Finally,  a directory  of  all  stations  under  the  node  is  provided  in  a node  data  file. 
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3.2.3  Sizing 

The  sizing  estimates  for  the  node  data  base  are  summarized  in  Table  4.2-10. 

The  number  of  records  within  each  data  file  (node,  station,  link,  trunk,  and  CCSD 
masters)  was  determined  using  a group  of  sites  in  the  European  theater  representa- 
tive of  a large  nodal  area.  The  estimates  for  the  station,  link,  trunk  and  CCSD  masters 
were  then  increased  by  fifty  percent  to  allow  for  future  expansion.  The  sites  chosen 
for  this  sizing  estimate  were  Donnersberg,  Bann,  Langerkopf,  Ramstein,  Pirmasens, 
Bad  Kreuznach,  Kaiserslautern,  Zweibrucken,  Lohnsfeld,  Landstuhl  and  Baunholder. 

In  sizing  the  fault  files,  the  number  of  faults  resident  in  the  node  data  base  at  any 
given  time  was  estimated  to  be  thirty  percent  of  the  total  number  of  circuits.  This 
figure  was  based  on  a study  performed  by  Computer  Sciences  Corporation*  in  February 
1971  on  the  Automated  Quality  Monitoring  Reporting  Subsystem  (AQMRS)  at  Coltano 
Italy.  This  study  showed  that  the  AQMRS  monitoring  function  identified  twenty  percent 
of  the  circuits  monitored  as  being  in  a degraded  condition.  Since  one  of  the  sources 
for  fault  inputs  is  ATEC  system  which  is  considerably  more  powerful  than  the  AQMRS, 
the  figure  of  thirty  percent  was  chosen  for  sizing. 

Sufficient  space  for  storing  up  to  5 station  measurements  for  half  of  the  circuits 
in  the  data  base  was  provided.  This  assures  that  approximately  half  of  the  total  number 
of  circuits  will  have  a constant  signal  level  suitable  for  monitoring. 

The  resulting  disk  space  requirements  for  the  node  was  estimated  to  be  approxi- 
mately 1.6  megabytes. 


♦Evaluation  of  USASTRATCOM  Automated  Quality  Monitoring  Reporting  Subsystem 
(AQMRS),  SCCC-TED-71-FR-22,  Computer  Sciences  Corporation,  February  1971. 
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NODE  DATA  R*iSE  STRUCTURE 


Total  = 50 


Fault  Detail  Pointer  to  the  first  record  in  the  Fault  Detail  Data  Integer 

Pointer  File  that  is  associated  with  the  given  link  number. 


Table  3.2-4.  Trunk  Master  Data  File  (Sheet  1 of  2) 
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Table  3 . 2-6.  Fault  Master  Data  File 


Isolation  Flag  Code  indicating  whether  or  not  the  fault  has  been  ASCII 
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Table  3 . 2-10.  Nodal  Level  Data  Base  Sizing 


3.3  SOFTWARE  CONSIDERATIONS  FOR  THE  NODE 


A preliminary  software  design  for  the  Node  has  been  performed  using  the 
THREADS  design  methodology.  This  process  is  described  in  detail  in  Section  1.4. 

In  the  following  subsections  a detailed  software  design  for  the  Node  level  of  unified 
control  is  presented  in  terms  of  the  THREADS  (identified  during  the  design  effort)  to 
support  the  functional  capabilities  discussed  in  Section  3. 1. 

For  each  nodal  function  a THREAD  flow  diagram  which  describes  the  proces- 
sing steps  required  in  accomplishing  the  function  and  the  routines  supporting  each 
processing  step  is  presented.  A sizing  analysis  is  then  provided  which  addresses 
individual  routine  size  requirements  as  well  as  overall  Node  processing  system  size 
requirements  including  estimates  of  lines  of  code  and  memory  occupancy.  Processor 
memory  requirements  are  then  addressed  including  support  software,  resident  data 
structures  and  overlay  techniques.  A parametric  processing  load  analysis  is 
provided  which  show's  processor  and  disk  load  requirements  for  the  Node  as  a 
function  of  various  system  event  occurrence  rates.  Finally,  the  general  character- 
istics of  processor  support  software  as  they  pertain  to  the  Nodal  level  of  unified 
control  are  discussed. 

3.3.1  Node  Software  Design 

The  following  paragraphs  present  a software  system  design  for  the  Node  in 
terms  of  55  Node  level  THREADS.  These  THREADS  are  derived  from  the  Node  level 
requirements  presented  in  Section  3. 1,  where  each  THREAD  supports  a specific 
functional  requirement.  The  THREADS  are  first  presented  in  a hierarchical  structure 
which  shows  all  software  capabilities  available  to  each  functional  element  of  unified 
control  at  the  Node  level.  Each  THREAD  is  additionally  described  in  a THREAD  flow 
diagram  which  shows  the  discrete  processing  requirements  and  individual  routines 
necessary  to  accomplish  the  prescribed  function.  Finally,  all  routines  identified  in 
the  THREAD  flow  diagrams  are  summarized  in  a hierarchical  computer  program 
structure  showing  the  various  levels  of  control  within  the  applications  software 
system. 


3.3. 1.1  Node  THREADS 


Figure  3.3-1  summarizes  the  THREADS  which  comprise  the  Node  level 
of  unified  control.  The  figure  shows  a hierarchy  of  THREADS  supporting  each 
operational  element  serviced  by  the  Node  including  the  Nodal  Controller,  Sector, 
Station  Controller,  ATEC,  AUTOVON,  and  AUTODIN  Switches. 

The  top  level  of  the  hierarchy  performs  I/O  and  preliminary  message 
processing  functions.  The  software  represented  by  these  THREADS  performs  line 
handling,  buffer  management,  and  task  scheduling  activities.  The  stimulus  to  these 
THREADS  is  generally  an  interrupt  or  other  condition  indicating  a call  for  input  or 
output  service,  while  the  response  is  a completed  I/O  operation  with  appropriate 
subsequent  processing  scheduled.  Each  subsequent  processing  task  is  supported 
by  a distinct  THREAD  located  on  the  second  level  of  the  hierarchy.  The  scheduling 
activities  performed  by  the  top  level  THREADS  serve  as  the  stimulii  to  the  various 
second  level  THREADS. 

The  second  level  THREADS  are  grouped  into  six  subtrees  corresponding  to  the 
six  sources  of  external  stimulus  to  the  Node.  These  groups  are  mapped  to  the  top 
level  THREAD  they  support  by  the  connectors  A through  F on  the  first  sheet  of  the 
figure.  To  examine  the  support  available  to  a given  Nodal  element  it  is  necessary  only 
to  inspect  the  corresponding  subtree  for  that  element. 

The  third  level  of  the  THREAD  hierarchy  contains  only  two  THREADS.  These 
THREADS  deal  exclusively  with  fault  entry  processing  in  support  of  the  Station 
Controller,  ATEC,  AUTOVON  and  AUTODIN  elements,  and  therefore  require  an 
additional  hierarchical  level  in  order  to  be  accessible  to  the  second  level  THREADS 
for  these  elements.  This  commonality  of  detailed  fault  entry  processing  is  possible 
since  each  of  the  elements  enumerated  above  is  considered  an  equally  valid  source  of 
fault  data  to  the  system.  Further,  all  faults  carried  by  the  system  are  structured  and 
accessed  in  a consistent  manner  regardless  of  the  source  of  the  fault  data.  The  minor 
syntactical  and  content  variations  in  fault  data  supplied  by  the  various  sources  are 
accommodated  in  the  second  level  fault  acceptance  THREADS  which  serve  as  pre- 
processors to  the  detailed  fault  entry  processing  THREADS  on  the  third  level. 
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The  THREADS  contained  in  Figure  3.3-1  are  presented  in  an  abbreviated 
format.  In  the  next  paragraph  each  THREAD  will  be  expanded  into  a flow  diagram 
in  order  to  show  the  detailed  processing  requirements  and  associated  software 
requirements  to  accomplish  the  function  supported  by  the  THREAD. 

3.3. 1.2  THREAD  Flow  Diagrams 

Figures  3.3-3  through  3.3-9  show  the  detailed  flow  diagrams  for  the  Node  level 
THREADS.  Each  figure  contains  the  diagrams  for  all  THREADS  which  support  a given 
Nodal  element  or  common  functional  requirement.  Table  3.3-1  summarizes  the 
contents  of  these  figures. 

The  basic  format  of  the  flow  diagram  is  shown  in  Figure  3.3-2.  The  stimulus 
and  response  information  will  be  the  same  as  indicated  in  the  abbreviated  formats  used 
in  the  THREAD  hierarchy.  However,  while  the  processing  information  is  summarized 
in  the  abbreviated  format,  it  is  expanded  into  a series  of  more  precise  steps  in  the  flow 
diagram.  Each  step  also  lists  the  computer  programs  necessary  to  support  the 
indicated  processing. 

The  supervisory  level  and  I/O  diagrams  are  shown  in  Figure  3.3-3.  These 
THREADS  divide  into  two  basic  types.  The  first  six  THREADS  address  input  processing 
of  data  from  each  Unified  Control  element  which  communicates  directly  with  the  Node. 

In  addition  to  input  handling  functions  they  perform  supervisory  scheduling  functions 
based  on  the  message  types  that  are  received.  The  remaining  three  THREA  DS  perform 
communications  output  handling  for  the  ATEC,  AUTOVON  and  Sector  interfaces. 

Figures  3.3-4  and  3.3-6  show  the  THREAD  diagrams  which  provide  support  to  the 
Node  and  Station  Controller  positions  respectively.  Many  of  the  requests  that  can  be 
made  from  these  positions  are  identical  and  utilize  common  software.  Among  the  types 
of  data  that  may  be  requested  at  these  positions  are  media  status,  detailed  fault  record 
information,  connectivity,  journal  contents,  and  summaries  of  outstanding  faults. 
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Figure  3. 3-5  shows  the  Sector  handling  software.  The  majority  of  the  mes- 
sages received  from  the  Sector  aie  of  three  general  types:  responses  to  requests  for 
data  from  other  points  in  the  unified  control  system,  requests  to  supply  data  to  other 
points  in  the  system,  and  fault  related  broadcast  messages.  Messages  are  also 
provided  for  issuing  control  directives  including  fault  responsibility  assignment, 
performance  of  configuration  updates  and  reroute  implementation.  Several  additional 
messages  are  provided  for  maintaining  data  base  integrity  including  connectivity 
modification  and  reroute  confirmation  messages.  In  these  two  cases,  the  data  base 
is  not  updated  until  confirmation  of  the  modification  has  been  made  by  the  responsible 
element. 


Figure  3.3-7  shows  the  preprocessing  THREADS  which  accept  ATEC  inputs. 
The  first  THREAD  accepts  fault  notification  messages  and  generates  detailed  fault 
records  from  the  message  data,  and  schedules  further  processing.  This  THREAD 
will  also  inform  ATEC  as  to  the  isolation  status  of  the  reported  fault  in  order  to 
avert  unnecessary  ATEC  fault  isolation  activities.  The  second  THREAD  accepts 
responses  to  status  request  messages  and  routes  them  to  the  requesting  position. 

The  AUTO  VON  and  AUTODIN  switch  preprocessing  THREADS  are  shown  in 
Figure  3.3-8.  Both  of  these  THREADS  generate  detailed  fault  records  from  the 
received  message  data  and  schedule  the  records  for  detailed  fault  entry  processing. 

Figure  3.3-9  shows  the  detailed  fault  entry  processing  THREADS.  These 
THREADS  perform  similar  processing  functions  but  derive  different  responses.  The 
first  THREAD  processes  new  faults  which  occur  on  media  where  no  higher  order 
faults  have  been  reported.  The  fault  is  therefore  assumed  to  be  a legitimate  problem 
on  the  CCSD,  trunk  or  link  as  reported.  The  second  THREAD  processes  faults  which 
may  be  due  to  higher  order  outages  or  degradations.  In  both  cases,  the  Media  and 
Fault  Files  are  updated  to  reflect  the  report.  If  the  fault  is  determined  to  be  un- 
related to  existing  higher  order  faults,  a check  is  made  to  determine  if  there  are  any 
lower  order  faults  currently  on  record  which  may  be  related  to  the  newly  reported 
fault.  All  such  faults  are  flagged,  linked  as  possibly  related  to  the  new  fault  and, 
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where  local  isolation  activities  are  taking  place,  such  activities  are  suspended  until 
resolution  of  the  new  fault.  A fault  notification  broadcast  message  on  the  new  fault 
is  then  prepared  and  forwarded  to  the  Sector. 

If,  on  the  other  hand,  the  new  fault  is  found  to  be  possibly  related  to  an  existing 
higher  order  fault  through  a comparison  of  relative  fault  severities  and  degrees  of 
degradation,  the  data  pertaining  to  the  new  fault  is  forwarded  to  the  position  responsi- 
ble for  the  existing  higher  order  fault  to  aid  that  position  with  fault  isolation. 
Additionally,  appropriate  local  notifications  are  generated  and  displayed. 

In  the  next  paragraph,  all  of  the  computer  programs  which  are  identified  in 
Figures  3.3-3  through  3.3-9  are  presented  in  a computer  program  hierarchy  in  order 
to  show  the  relationships  of  the  various  routines  and  to  summarize  the  applications 
software  system  for  the  Node. 

3. 3. 1.  3 Computer  Program  Hierarchy 

All  of  the  routines  which  are  identified  in  the  Node  level  THREADS  have  been 
structured  into  a six-level  program  hierarchy.  In  determining  the  appropriate  level 
for  a given  routine,  two  guidelines  are  followed.  First,  a given  routine  may  call 
only  those  routines  which  reside  at  lower  hierarchical  levels.  The  application  of 
this  rule  ensures  that  the  levels  of  the  hierarchy  indicate  the  various  levels  of  control 
within  the  software  system.  Second,  each  level  of  the  hierarchy  should  be  functionally 
homogeneous.  That  is,  routines  which  perform  similar  functions  should  be  grouped 
at  a given  hierarchical  level. 

Figure  3.3-10  shows  the  program  hierarchy  for  the  Node  level  of  unified 
control. 

The  top  level  of  the  hierarchy  contains  the  NODE  SUPERVISOR  which  controls 
execution  of  all  scheduled  events  in  the  software  system. 

The  second  level  contains  the  interrupt  driven  I/O  drivers  and  a series  of 
message  processors.  Each  message  processor  controls  the  support  activities  for 
one  of  the  major  input  sources  at  the  node.  In  general,  these  routines  supervise 
message  decoding/ validation  and  perform  overlay  retrieval. 
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The  third  level  of  the  hierarchy  contains  the  routines  responsible  for  per- 
forming major  operational  functions.  Such  functions  include  processing  individual 
controller  requests,  and  individual  sector  message  types. 

The  fourth  level  provides  significant  support  functions  to  the  various  third  level 
routines.  For  example,  the  third  level  NODE  CONNECTIVITY  DISPLAY  PROCESSOR 
depends  heavily  on  the  four  connectivity  RETRIEVAL  routines  on  this  level.  This 
amount  of  functional  support  minimizes  duplication  of  software  between  the  various 
operational  function  routines  on  the  third  level.  In  addition,  it  provides  a level  of 
insulation  between  the  functionally  oriented  routines  in  the  upper  levels  and  the 
various  data  base  structures  employed  in  the  lower  levels  of  the  hierarchy. 

The  fifth  level  consists  largely  of  file  managers  for  the  various  components  of 
the  data  base.  These  file  managers  rely  largely  on  the  sixth  level  generic  data  base 
management  support  routines  FIND,  GET,  CREATE,  DELETE  and  MODIFY  for 
access  to  the  various  files.  Additional  system  support  activities  supplied  on  the  sixth 
level  include  error  processing,  message  type  decoding  and  I/O  buffer  management. 

3.3.2  Software  Sizing 

The  following  two  paragraphs  present  a software  sizing  analysis  for  the  Node.  In 
the  first  paragraph,  each  routine  identified  during  the  design  effort  is  addressed  in 
terms  of  estimated  lines  of  code  and  program  and  data  occupancy  requirements.  The 
second  paragraph  then  presents  processor  memory  requirements  based  on  a two- 
level  overlay  structure. 

3.3.2. 1 Program  Sizing 

The  sizing  of  the  programs  presented  in  this  paragraph  is  based  on  an  estimation 
of  the  number  of  lines  of  HOL  code  required  to  implement  each  routine  in  the  Node 
program  hierarchy  (Paragraph  3.3. 1.3),  plus  additional  memory  required  to  accommodate 
data  for  each  routine.  This  sizing  includes  applications  software  and  operating  system 
enhancements  only  and  assumes  that  the  host  computer  supplies  support  software 
capabilities  as  described  in  Paragraph  3.3.4. 
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Table  3.3-2  summarizes  the  program  sizing  for  the  Node.  The  program 
occupancy  for  each  routine  is  based  on  an  expansion  factor  of  15  bytes  of  storage  for 
each  line  of  HOL.  This  ratio  is  typical  of  16-bit  word  length  machines  using  current- 
ly available  HOL  compilers.  Further  justification  of  this  expansion  ratio  is  provided 
in  Section  1.4.  Where  applicable,  the  data  occupancy  for  each  routine  includes  buffer 
and  table  space  requirements.  Without  the  use  of  overlays,  the  total  memory 
requirement  for  the  Node  applications  software  is  236K  bytes. 

3. 3. 2.  2 Processor  Memory  Requirements 

The  software  system  described  in  Section  3.3. 1 is  functionally  partitionable 
and  is  susceptible  to  incorporation  into  an  overlay  structure.  The  use  of  overlays, 
where  on-line  secondary  storage  capabilities  are  available,  minimizes  processor 
memory  requirements  by  retaining  low  demand  software  in  secondary  storage. 

An  overlay  structure  for  the  Node  software  was  developed  by  dividing  the 
routines  contained  in  the  Node  program  hierarchy  into  three  categories:  resident, 
element  support  and  functional  support. 

The  resident  routines  are  high  demand  routines  which  support  supervisor/ 
control  of  all  processing  functions.  Such  routines  as  the  NODE  SUPERVISOR,  the 
I/O  drivers,  the  generic  data  base  access  routines  and  the  destination  processor  are 
considered  in  this  category  since  they  are  used  to  support  all  nodal  elements  and 
most  of  the  functional  routines.  Table  3.3-3  summarizes  the  resident  routines  for 
the  Node.  These  routines  require  55,350  bytes  of  memory. 

The  routines  which  compose  the  support  overlays  are  also  summarized  in 
Table  3. 3-3  according  to  the  nodal  element  which  they  support.  The  positions  and 
their  respective  support  sizes  are  summarized  below; 


NODAL  CONTROLLER  SUPPORT 

32,925  bytes 

SECTOR  SUPPORT 

34, 050  bytes 

STATION  CONTROLLER  SUPPORT 

30, 675  bytes 

ATEC 

33, 300  bytes 

AUTODIN  REPORT  PROCESSOR 

31, 050  bytes 

AUTOVON  MODULE 

31, 800  bytes 
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The  routines  which  are  used  for  supporting  the  Nodal  Controller,  the  Station 
Controller  and  the  Sector  are  defined  to  be  those  routines  that  would  be  needed  by  any 
of  the  functional  routines  supported  by  the  given  element.  The  routines  which  are 
part  of  the  ATEC,  AUTODIN,  and  AUTOVON  overlays  include  both  the  support  and 
functional  routines  except  for  the  detailed  fault  processing  routines. 

The  routines  comprising  the  functional  overlays  for  the  Nodal  Controller,  Sector 
and  the  Station  Controller  are  summarized  in  Table  3.  3-4.  Depending  on  the  function 
to  be  performed,  only  one  of  these  overlays  would  be  in  memory  at  any  time. 

In  order  to  determine  the  amount  of  memory  required  at  the  node  for  applica- 
tions software,  it  is  necessary  to  add  the  memory  requirements  for  the  resident 
routines,  support  overlay  routines  and  the  largest  ictional  overlay  module  for  each 
nodal  element.  Table  3.3-5  shows  that  the  largest  memory  requirement  occurs  for 
processing  Sector  input.  In  this  case  the  applications  software  requires  103,650 
bytes  of  main  memory. 

In  addition  to  the  applications  software  requirements,  the  processor  memory 
must  accommodate  the  resident  portion  of  a disk  based  operating  system.  Based  upon 
currently  available  real-time  operating  system  software,  a residency  requirement  for 
an  operating  system  providing  the  support  outlined  in  Section  3.3.4  is  12, 000  bytes. 
This  does  not  include  occupancy  within  the  operating  system  for  the  I/O  drivers  and 
buffer  areas  which  were  sized  as  part  of  the  applications  software.  The  total  node 
memory  requirements  is  now  determined  to  be  116K  bytes. 

3.3.3  Node  Processing  Load 

A worst  case  sustained  load  analysis  is  presented  in  this  paragraph.  Both 
processor  and  disk  utilizations  are  considered  because  of  the  large  amount  of  data 
base  access  activity  required  to  support  unified  control  functions.  The  utilizations 
are  parametrically  derived  and  presented  in  a series  of  curves  which  show  utilization 
as  a function  of  the  rate  of  station  level  fault  entry  and  sector  level  fault  notification. 


Table  3.3-6  summarizes  the  set  of  worst  case  algorithms  on  which  the  load 
analysis  is  based.  Each  algorithm  is  analyzed  for  the  number  of  assembly  language 
instructions  executed  and  the  number  of  disk  accesses  performed  for  a single  execution 
of  the  algorithm.  The  flowcharts  and  detailed  analysis  of  these  algorithms  are 
contained  in  Appendix  A to  this  report. 

Algorithm  N1  performs  processing  of  fault  notification  broadcast  messages 
received  from  the  sector.  Algorithms  N2,  N3,  N4,  and  N5  perform  fault  entry 
preprocessing  for  the  various  sources  of  fault  data  at  the  station  level.  Algorithm  N6 
accepts  the  preprocessed  fault  data  and  performs  detailed  fault  entry  processing. 

This  algorithm  is  executed  once  for  each  execution  of  algorithms  N2  through  N5. 
Algorithm  N7  is  the  worst  case  display  request  that  can  be  made  from  a controller 
position.  This  algorithm  will  be  used  later  in  this  paragraph  to  establish  average 
and  worst  case  operator  response  times. 

Table  3.3-7  shows  die  derivation  of  the  worst  case  I/O  support  load.  For  each 
element  interfaced  at  the  node  the  maximum  aggregate  bandwidth  is  computed  in  terms 
of  the  number  of  assembly  level  instructions  required  per  second  to  effect  the  I/O 
transfers.  For  the  worst  case  it  is  assumed  that  data  will  be  passed  a character  at 
a time  on  the  processor  I/O  bus.  From  this  table  the  I/O  load  at  the  node  is  6,900 
instructions/sec. 

Figure  3.3-11  presents  the  derivation  of  the  processing  load  at  the  Node. 

From  Equation  (1)  it  is  seen  that  the  total  processing  load  is  the  sum  of  the 

loads  supporting  station  level  fault  entry  (PrlIIT  ),  sector  level  fault  notification 

rAULl 

cycle  stealing  due  to  disk  activity  and  communications  I/O  (P  , ). 

SECTOR  DloK  I/O 

Equation  (2)  shows  that  the  fault  entry  and  fault  notification  processing  loads  are  the 
products  of  the  single  occurrence  loads  and  occurrence  rates.  Equations  (3)  and  (4) 
show  the  computation  of  the  single  occurrence  loads  for  station  level  fault  entry  and 
sector  level  fault  notification  respectively.  Since  the  sustained  load  will  be  computed 
for  a one  minute  interval,  a time  conversion  factor  must  be  included  to  find  the  effective 
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average  second  load.  Equation  (5)  accounts  for  memory  cycle  stealing  due  to  the 
disk  DMA  activity.  An  average  disk  access  size  of  one  256  word  block  is  assumed. 
Equation  (6)  shows  the  communications  I/O  load.  The  worst  case  I/O  load  as 
presented  in  Table  3.3-7  is  assumed.  By  rewriting  Equation  (2),  Equation  (7)  now 
shows  the  node  processing  load  as  a function  of  the  rate  of  fault  entry  and  fault 


notification.  This  equation  is  plotted  in  Figure  3.3-12  for  values  of  R from 

FA  U LT 


0 to  30  and  from  0 to  20.  Because  the  load  is  distributed  evenly  over  the 
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fault  occurrence  interval  of  one  minute,  the  load  on  the  processor  is  relatively  low. 


Figure  3.  3-13  shows  the  derivation  of  the  disk  load  at  the  Node.  Equation  (1) 
shows  that  the  total  disk  load  is  the  sum  of  the  disk  loads  supporting  fault  entry  and 
sector  fault  notification  processing.  These  quantities  are  a function  of  the  rate  of 
fault  related  event  occurrence  as  shown  in  Equation  (2).  Equation  (5)  shows  the 


total  disk  load  as  a function  of  these  occurrence  rates.  Figure  3.3-14  plots  D as 

N 


a function  of  R and  R_,_  The  100  percent  utilization  line  for  a typical 
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moving  head  disk  with  sufficient  capacity  to  accommodate  the  Node  data  base  is  also 
indicated  on  this  figure.  This  utilization  threshold  is  based  on  a 50  millisecond 
average  access  time. 


It  is  seen  from  the  projected  processor  and  disk  loads  that  the  nature  of  unified 
control  processing  is  highly  I/O  bound.  Disk  utilization  is  therefore  the  critical 
factor  in  accommodating  a worst  case  situation. 


Consider  the  case  where  the  following  unique  faults  are  reported  from  the 
station  level  at  a single  Node  within  a one  minute  period: 


A TEC 
AUTOVON 
AUTODIN 
STATIONS 


5 

2 

2 


10  (one  per  station) 
19 
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Reading  the  disk  load  from  Figure  3.3-14  it  can  be  seen  that  as  many  as  20  fault 
notifications  can  be  received  from  the  Sector  during  this  same  one  minute  interval 
before  the  disk  load  approaches  saturation.  If  the  utilization  of  the  disk  were  to  reach 
100  percent,  a degradation  in  system  response  time  would  result  for  as  long  as  the 
saturating  conditions  persisted.  In  view  of  the  nature  of  the  data  under  consideration 
and  the  operator  limiting  speeds  for  entry  of  a large  portion  of  the  data,  this  worst 
case  could  not  be  sustained  for  a significant  length  of  time. 

The  average  load  on  the  Node  is  considerably  less  than  cited  above  since  the 
average  daily  fault  occurrence  rate  for  the  entire  European  DCS,  assuming  automated 
monitoring  capability,  is  on  the  order  of  20  percent  of  all  circuits. 

Assuming  the  largest  node  to  have  jurisdiction  over  2000  circuits,  the  average 
fault  occurrence  rate  at  this  node  is  400  faults/day.  Further  assume  that  half  of 
these  faults  occur  during  normal  working  hours.  The  average  number  of  faults 
during  this  period  is  then  25  faults/hour  or  less  than  one-half  fault/minute. 

Algorithm  N7  can  be  used  to  determine  operator  response  times  as  a function 
of  the  relative  load  on  the  Node  processor  and  disk.  The  algorithm  requires  that 
18,012  instructions  and  16  disk  accesses  be  performed.  The  response  time  will  be 
dominated  by  disk  access  time.  The  disk  activity,  assuming  no  contention  for  disk 
resources  would  require  800  milliseconds  (16  accesses  @ 50  milliseconds/access). 

Assuming  a relatively  slow  processing  capability  (8  microsecond  average 
instruction  time)  the  processing  would  require  144  milliseconds  (no  contention). 

The  total  time  until  the  connectivity  request  processing  is  completed  and  the 
data  is  ready  for  display  is  then  . 944  seconds  when  no  other  activity  is  ongoing. 

Assumingthatthe  Node  is  processing  20  station  level  faults  and  20  sector  level 
fault  notifications  the  response  time  for  this  request  then  degrades  to  2. 01  seconds 
(1. 75  seconds  total  for  disk,  . 256  seconds  for  processing). 
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3.3.4  Support  Software 

The  support  software  required  for  the  unified  control  system  can  be  separated 
into  operational  software  and  development  software.  As  part  of  the  operational  software, 
a disk-oriented  operating  system  is  needed.  The  operating  system  should  include  such 
things  as  an  overlay  loader/linker,  a task  scheduler  capable  of  swapping  programs  as 
needed  and  a capable  file  manager  to  control  all  of  the  programs  and  files  which  are 
located  on  disk. 

Diagnostic  software  should  also  be  provided  to  help  detect  and  isolate  system 
problems  such  as  malfunctions  in  the  processor  and  I/O  controller  hardware  or  in  the 
peripherals. 

Although  the  software  was  sized  to  include  some  general  and  simple  data  base 
functions,  it  would  be  possible  to  use  a data  base  management  system  instead  if  one  was 
available.  The  DBMS  features  should  include:  a database  description  to  define  files, 
records,  and  inter-record  relationships;  a database  manipulation  language  to  create, 
delete  and  modify  records;  some  basic  utility  support  routines  to  load/unload  the  database 
files  and  initialize  the  database.  Currently  there  are  two  types  of  database  structures 
available  for  minicomputers.  They  can  be  separated  into  network  models  (i.e.,  TOTAL, 
HP's  IMAGE)  and  CODASYL  models  (i.e.,  DEC'S  DBMS-11). 

Vendor  supplied  database  management  software  for  minicomputers  is  a relatively 
new  development.  Of  the  lower  powered  network  structured  management  systems,  TOTAL, 
an  adaptable  package  provided  by  CINCOM,  has  been  the  most  widely  installed  system  by 
minicomputer  manufacturers  including  Varian,  Harris,  and  Interdata.  Other  manufacturers 
are  currently  in  various  stages  of  negotiation  with  CINCOM  to  provide  TOTAL. 

The  CODASYL  based  database  systems  are  gaining  popularity  and  although  not 
currently  available  on  many  minicomputer  systems  should  be  available  from  increasing 
numbers  of  manufacturers  in  the  future. 
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The  nature  of  the  data  management  functions  required  in  unified  control  is  such 
that  either  type  of  data  base  manager  could  be  used.  Although  the  availability  of  the 
CODASYL  capabilities  would  reduce  the  complexity  of  the  various  data  file  structures, 
such  capabilities  are  not  likely  to  be  available  on  low  end  processors  in  the  immediate 
future. 

For  the  development  of  the  system  such  software  as  a higher-order  language 
compiler  (FORTRAN,  COBOL,  PL-I,  etc.  ),an  assembler,  a text  editor  and  a symbolic 
debugger  should  be  included.  The  higher-order  language  compiler  and  the  debugger 
are  used  in  the  development  of  applications  programs.  The  assembler  is  needed  for  any 
I/O  driver  or  system  software  modifications.  The  text  editor  is  needed  to  allow  for 
program  corrections  in  an  on-line  developmental  environment.  The  above-mentioned 
operational  and  development  software  would  provide  a basic  system  with  the  minimal 
capabilities  needed  to  develop  and  operate  the  unified  control  system. 
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Figure  3.3-1.  Node  Controller— ►Node  (Sheet  2 of  6) 


Processing 


Figure  3.3-3.  Supervisory  and  I/O  Level  THREAD  Diagrams  /Sheet  1 of  2) 


Figure  3.3-4.  Node  Controller ►Node  THREAD  Diagrams 

(Sheet  3 of  4) 


Figure  3.3-6.  Station  Controller  —►Node  THREAD  Diagrams 


Figure  3.3-9.  Nodal  Fault  Processing  (Cl)  THREAD  Diagram 
(Sheet  l of  2) 
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Figure  3. 3-10.  Computer  Program  Hierarchy 
for  the  Node 
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where 


Number  of  instructions  due  to  X 


Rate  of  occurrence  of  X 
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where 


D = Disk  Load  (see  Figure  3.3-13) 


6,900  (see  Table  3.3-7) 
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Figure  3.3-11.  Derivation  of  the  Node  Processing  Load 


(Inst/Sec) 


Figure  3.3-12.  Node  Processing  Load 
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where 


A^  = Number  of  accesses  due  to  X 
R^  = Rate  of  occurrence  of  X 
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Table  3.3-1.  Guide  to  Node  Level  Detailed  THREAD  Diagrams 
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Table  3.3-3.  Node  Resident  and  Support  Overlay  Sizing  Summary 
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Manual  Measurement  Accept 

Manual  Measurement  Destination  Processor  (X 
Free  Text  Message  Processor 


Related  Fault  Record  Marmot 
Precedence  Determine  (N> 
AL’TOVOX  Trunk  Translater 


Table  3. 3-4  (Sheet  5).  Node  Functional  Overlay  Structure  Sizing  Summary 


Table  3.3-5.  Determination  of  the  Largest  Memory  Occupancy 
Requirement  for  the  Node 
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Largest 

Resident 

Support 

Functional 

Total 

Nodal  Element 

Routines 

Overlay 

Overlay 

Occupancy 

Nodal 

Controller 

55,350 

32,925 

11,625 

99,900 

Sector 

55,350 

34,050 

25,500 

114,900 

Station 

Controller 

55,350 

30, 675 

15,000 

101,025 

ATEC 

55,350 

33,300 

15,000 

103, 650 

AUTODIN 

Report  Proc 

55,350 

31,050 

15,000 

101,400 

AUTO VON 

Module 

55,350 

31,800 

15,000 

102,150 

Table  3.3-6.  Summary  of  Algorithms  for  the  Node 


J- 

Algorithm 

Function 

# ASM 
Inst 

# Disk 
Accesses 

Mi 

N1 

Process  Fault  Notification  Broadcasts 

T 

from  Sector 

3490 

28 

1 

N2 

Accept  Fault  Entry  from  Stations 

395 

— 

T* 

N3 

Accept  Fault  Entry  from  AUTOVON 

f 

* 

Module 

415 

1 

N4 

Accept  Fault  Entry  from  AUTODIN 

Report  Processor 

480 

1 

* • 

N5 

Accept  Fault  Entry  from  ATEC 

415 

1 

[ 

N6 

Perform  Detailed  Fault  Entry 

Processing 

3330 

27 

N7 

Display  CCSD  Connectivity  to  Node 

Controller 

18012 

16 

Aggregate 


Source 

No. 

Lines 

Line 

Rate 

(bps) 

No.  Byte 
Transfers 
(B/Sec/Line) 

Aggregate 

Transfers/ 

Sec 

Load 

Transfers 

(Inst) 

Aggregate 

Load 

(Inst/Sec) 

Sector 

2400 

300 

600^ 

3 

1800 

Stations 

10 

150 

19 

190 

3 

570 

VON  Module 

2400 

300 

600-^ 

3 

1800 

DIN  Report  Proc 

1 

75 

10 

10 

3 

30 

ATEC 

2400 

300 

1/ 

600- 

3 

1800 

Node  Controller 

1 

2400 

300 

300 

3 

900 

Total  I/O  Load  - 6,900  Inst/Sec 


3.4  HARDWARE  CONSIDERATIONS  FOR  THE  NODE 

In  the  following  subsections  the  hardware  considerations  for  the  Node  level  of 
unified  control  including  processor,  peripheral  equipment,  and  processor  interface 
characteristics  are  addressed. 

3.4.1  Node  Processor 

The  Node  processing  system  as  described  in  Section  3.3  largely  performs  data 
base  management  and  display  processing  functions.  A basic  characteristic  of  such 
functions  is  that  they  are  highly  I/O  bound  by  disk  and  terminal  access  requirements 
as  demonstrated  by  the  load  analysis  presented  in  Paragraph  3.3.3.  Taking  the  worst 
case  functional  load  determined  in  this  paragraph,  and  applying  a task  switch  overhead  of 
1 millisecond/switch,  the  switching  overhead  can  be  estimated  in  the  worst  case  to  be 
40  milliseconds  (one  switch  for  each  message /request  processed).  The  sustained  Node 
processing  load  in  a multiprogrammed  environment  can  now  be  determined. 


Depending  upon  the  relative  speed  of  the  Node  processor,  this  constitutes  a 
varying  absolute  load.  The  loads  for  three  classes  of  16-bit  word  length  minicomputers 
are  summarized  below: 

8 microsecond  average  instruction  time  - 0.113 

5 microsecond  average  instruction  time  - .071 

2. 5 microsecond  average  instruction  time  - . 036 

As  can  be  seen  from  these  loads,  assuming  a relatively  low  speed  processor,  the 
sustained  real  time  load  is  on  the  order  of  11. 3 percent.  At  the  rates  suggested  in  this 
report  processing  speed  is  not  a critical  factor  in  accommodating  the  real  time  functions 
of  the  Node. 

The  processor  memory  requirement  for  the  Node  is  estimated  to  be  116K  bytes 
(Paragraph  3.3.2).  The  Node  processor  should  at  a minimum  support  a memory 
configuration  adequate  to  satisfy  this  requirement. 
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In  order  to  provide  future  functional  expansion,  the  processoi  should  provide 
for  considerable  memory  expansion  beyond  the  initial  unified  control  requirement. 
Allowing  100  percent  growth  capability  would  place  a maximum  memory  size  require- 
ment of  256K  bytes  on  the  Node  processor.  Memory  cycle  time  should  not  exceed  1 
microsecond. 

Additional  hardware  requirements  on  the  Node  processor  include  a power  fail/ 
auto  restart  capability,  hardware  bootstrap  loading,  real  time  clock  for  time  scheduled 
event  control,  and  an  operator  control  panel  as  an  aid  to  field  maintenance  personnel. 

The  Node  processor  should  also  provide  off-the-shelf  interfaces  for  all  of  the 
required  Node  peripherals  and  communications  interfaces  described  in  the  following 
paragraphs. 

An  important  consideration  for  the  Node  processor  is  the  availability  of  proven 
support  software.  This  software  should  include  a real-time  disk  operating  system 
that  supports  multi-tasking,  foreground/background,  overlay  supervision,  random  file 
management,  buffering,  and  spooling.  Software  peripheral  drivers  should  be  available 
for  the  standard  unified  control  peripherals.  The  processor  should  support  interactive 
system  control,  interactive  text  editing,  interactive  debugging,  and  macro  assembly. 
To  minimize  the  memory  requirements  for  the  operational  configuration,  a relocatable 
dynamic  loader  is  essential.  In  order  to  minimize  software  development  costs  it  is 
necessary  that  the  processor  support  a high  order  language  with  library  support  for 
bit  manipulation,  formatted  input/output,  and  data  conversion.  Data  base  management 
software  operational  under  the  real  time  operating  system  and  HOL  compiler  would  be 
an  effective  substitute  for  the  generic  data  base  management  software  included  with  the 
Node  software  design.  The  use  of  data  base  management  software  would  reduce  the 
amount  of  applications  code  in  the  system  by  an  amount  varying  with  the  power  of  the 
data  base  management  package. 

In  order  to  minimize  logistic  problems  (maintenance,  spares  provisioning)  and 
to  support  expansion  into  future  higher  bandwidth  applications  at  the  Node,  the 
processor  should  be  a member  of  an  upward  compatible  family  of  hardware. 
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3.4.2  Node  Peripherals  and  Interfaces 


Figure  3.4-1  shows  the  hardware  configuration  for  the  Node.  The  Node  hard- 
ware complement  includes  a processor  configured  with  a minimum  of  128K  bytes  of 
main  memory,  5M  bytes  of  random  access  disk  storage  for  data  base  and  applications 
overlay  storage,  a magnetic  tape  storage  device  for  long  term  journal  retention,  a 
KB/CRT  with  local  printing  capability  to  support  the  Node  Controller  position,  and 
up  to  ten  KB/CRT  terminals  with  optional  local  printing  capabilities  to  support  the 
Station  Controller  positions. 

Communications  interfaces  to  the  Node  include  three  2400  bps  serial  synchronous 
channels  to  support  VON  MODULE,  ATEC,  and  Sector  communications,  and  a 75  bps 
serial  interface  to  the  AUTODIN  Report  Processor. 

The  Node  system  is  highly  dependent  on  random  data  storage  and  retrieval.  The 
data  base  requirement  analysis  in  this  report  indicates  that  a minimum  of  1. 7M  bytes 
of  data  is  necessary  for  the  Node  data  base.  A 5M  byte  disk  capacity  accommodates 
these  requirements  and  provides  moderate  expansion.  Average  access  time  for  the 
disk  should  be  less  than  50  milliseconds  because  of  the  projected  high  disk  utilizations. 
This  disk  should  include  a removable  cartridge  to  facilitate  configuration  management, 
and  the  controller  should  support  at  least  four  disk  drives  to  accommodate  future 
expansion.  A standard  processor  interface  to  the  controller  is  necessary. 

The  magnetic  tape  unit  should  include  a standard  processor  interface  providing 
formatting  logic,  and  DMA  I/O  operation.  If  batch  analysis  of  journal  data  is  desired 
and  existing  facilities  are  to  be  used  to  perform  the  analysis,  consideration  should  be 
made  for  compatible  tape  recording  formats. 

Unified  control  functions  involve  a high  degree  of  operation  interaction  and  are 
dependent  upon  an  operator  input  and  output  device  that  allows  powerful  operator  Inter- 
action at  minimal  skill  levels.  An  intelligent  alphanumeric  self-refreshed  CRT  display 
with  keyboard  is  necessary  for  providing  unified  control  interfaces  to  Node  and  Station 
Controllers. 
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Figure  3.4-1.  Node  Hardware  Configuration 
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The  display  should  provide  a viewing  area  of  24  80-character  lines  of  text  and 
should  provide  data  highlighting  such  as  underlining,  variable  intensity,  reverse  video, 
and  character  blinking.  An  audio  alarm  is  required  so  that  the  operator  can  be  alerted 
upon  receiption  of  new  data.  The  keyboard  should  have  a standard  typewriter  format 
and  should  supply  multiple  user  definable  function  keys.  The  terminal  should  have  a 
character  set  including  upper  and  lower  alphanumeric  characters  and  all  ASCII  control 
characters.  The  terminal  should  optionally  operate  synchronously  and  asynchronously 
at  a data  rate  of  at  least  2400  baud  using  industry  compatible  interfacing  standards. 
Block  and  character  transmission  capabilities  should  be  supported  to  simplify  inter- 
active data  entry.  The  terminal  should  have  a self-test  feature  to  support  fault 
isolation. 

In  addition  to  the  preceding  requirements,  it  is  desirable  that  the  terminal 
support  internal  storage  for  multiple  page  displays.  Protected  fields  and  field  tabu- 
lations are  also  desirable  to  simplify  data  entry.  The  terminal  should  also  be  capable 
of  providing  local  hard  copies  of  screen  data.  This  capability  should  be  provided  to 
the  Nodal  Controller  and  selected  Station  Controllers  in  areas  with  significantly  high 
concentrations  of  circuits. 

The  synchronous  communications  channels  used  for  A TEC,  VON,  and  Sector 
communications  should  provide  full-  and  half-duplex  operation  at  a minimum  rate  of 
2400  baud  with  programmable  sync  character  and  programmable  character  size.  The 
2400  baud  rate  will  allow  a maximum  fault  notification  message  throughput  of  10 
messages/second  assuming  a 30  byte  message.  Since  the  average  fault  occurrence 
rate  is  much  less  than  this  amount  for  the  entire  DCS,  the  broadcast  function  is  easily 
accommodated  by  this  rate.  The  interface  should  also  provide  MODEM  Control  and 
compatability  with  industry  standard  synchronous  MODEMS.  Hardware  error  code 
generation  and  checking  would  be  desirable  to  minimize  processor  line  handling 
overhead. 


SECTION  4 - SECTOR  REQUIREMENTS 
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4.1  FUNCTIONAL  DESCRIPTION 

This  functional  description  encompasses  the  functions  performed  at  the  sector 
level  of  its  unified  control  system.  In  the  detailed  flowcharts  that  follow  many  connec- 
tions between  pages  were  required  because  of  the  complexity  of  the  diagrams.  A con- 
tinuation to  or  from  a different  page  is  shown  by  a circle  with  a number  in  it.  The 
numbering  system  is  the  same  as  that  used  on  the  general  flowchart,  -- E-a-circle  con- 
tains  S3-1  the  flow  continues  on  Sheet  3 of  the  sector  level  flowchart,  the  second 
number  distinguishing  different  inputs  on  the  same  page.  A single  circle  indicates  the 
flow  is  information  only,  and  two  concentric  circles  indicate  that  the  flow  is  control 
and  direction  as  well  as  information. 

The  majority  of  the  functions  illustrated  within  the  sector  level  are  envisioned 
as  being  automatically  processed.  At  several  points,  however,  operator  intervention 
is  required.  This  is  indicated  within  the  flowcharts  by  the  dashed  lines. 

Figure  4.1-1  is  the  functional  flowchart  for  the  sector.  Sheet  1 shows  the  in- 
formation distribution  function  that  is  performed  by  the  sector  to  inform  all  parts  of 
the  network  that  are  affected  by  any  reported  degradation.  Information  from  the  nodes 
within  a sector  that  concerns  status  information  about  a link,  trunk,  or  circuit 
© first  updates  the  sector  data  base  . The  routine  on  Sheet  3 is  initiated  to 
examine  the  possibility  of  establishing  a reroute  if  the  problem  is  an  outage.  The 
information  is  also  forwarded  to  the  ACOC  ^d)  . 

The  sector  next  determines  if  the  report  could  affect  any  links,  trunks,  or  cir- 
cuits outside  of  the  nodal  area  that  reported  the  problem  . If  not,  the  routine 
stops  since  the  node  is  responsible  for  isolating  the  fault  and  will  inform  the  sector 
when  the  status  of  the  condition  changes.  If  the  affect  does  leave  the  reporting  nodal 
area,  the  sector  will  distribute  a fault  notification  to  all  of  the  other  nodes  which  are 
possibly  affected  within  the  sector  . For  example,  if  a node  reports  a trunk 
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Figure  1.1-1.  Sector  Level  Functional  Flowchart  (Sheet  1 of  3) 


problem,  all  other  nodes  through  which  the  trunk  passes  are  informed  of  the  fault. 

Also,  any  node  that  has  a circuit  which  rides  on  that  trunk  at  some  point  on  its  path, 
although  the  trunk  itself  is  not  in  the  nodal  area,  will  be  informed  . If  the  nodal 
area  reporting  the  fault  does  not  contain  the  station  responsible  for  manual  fault  is- 
olation, the  sector  will  also  forward  all  of  the  detailed  fault  information  to  the  nodal 
area  that  is  responsible.  At  this  point  status  information  that  was  received  from  the 
ACOC  concerning  intertheater  links,  trunks,  and  circuits  (entering  at  Sl-2  from  Sheet  3) 
also  enters  the  routine  and  is  distributed  to  the  appropriate  nodes.  The  reports  are 
then  examined  to  determine  if  any  links,  trunks  or  circuits  could  be  affected  outside 
of  this  sector  . If  so,  information  on  the  problem  is  sent  to  the  other  sectors 
involved  . Detailed  fault  information  is  also  sent  to  another  sector  if  it  contains 
the  nodal  area  responsible  for  directing  manual  isolation  on  that  particular  fault. 

Similar  information  received  from  other  sectors  © updates  the  sector  data 
base  © , also  initiating  the  reroute  routine  on  Sheet  3,  and  is  distributed  to  all  of 
the  nodes  within  the  sector  that  may  be  affected  by  the  problem  . The  informa- 
tion is  then  examined,  as  in  the  information  originating  within  the  sector 
to  determine  if  it  is  a newly  reported  fault  . If  not,  the  routine  stops,  since  the 
information  will  be  an  update  or  closure  of  a previously  reported  fault,  and  no  further 
action  is  required  by  the  sector  beyond  distributing  the  information.  If  it  is  a new 
fault,  and  the  problem  is  on  a link  , the  sector  maintains  the  status  of  the  problem, 
but  takes  no  further  action  . In  the  case  of  link  troubles  the  nodes  responsible 
will  automatically  direct  the  terminating  stations  involved  to  coordinate  for  fault 
isolation,  ff  the  problem  is  not  on  a link  , the  fault  isolation  routine  on  Sheet  2 
is  initiated. 

If  the  report  from  the  node  is  not  status  information  on  a link,  trunk,  or  circuit 

, it  will  be  either  quality  assurance  measurements  or  the  report  of  a harzardous 
condition  at  a station.  If  it  is  concerning  a hazardous  condition  , the  information 
will  be  stored  in  the  sector  data  base  . The  sector  controller  will  be  kept  in- 
formed of  HAZCON’s  within  the  sector  by  receiving  displays  of  the  information  as  it 
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is  reported  (o)  . Information  on  hazardous  conditions  will  also  be  forwarded  to  the 
ACOC  ©•  1 the  information  is  quality  assurance  measurements  , the  data 
will  be  journaled  by  the  sector  ((5)  for  reference  at  a later  time. 


Sheet  2 of  the  flowchart  shows  the  fault  isolation  routine  that  is  performed  at  the 
sector  for  trunk  or  circuit  problems.  First,  the  sector  checks  to  see  if  any  of  the 
nodes  involved  are  equipped  with  ATEC  to  monitor  the  trunk  or  circuit  in  question  . 

If  not,  and  the  problem  is  on  a circuit  (^b)  , the  data  base  is  examined  to  determine 
if  the  circuit  should  have  a known  signal  level  that  could  be  monitored  . If  it  does, 
or  if  the  problem  is  on  a trunk  ^T)  , the  sector  will  send  the  indication  to  the  appropriate 
nodes  to  proceed  with  the  manual  level  check  . The  nodes  will  return  the  results 
to  the  sector  (entering  at  S2-2).  If  no  problems  were  revealed  at  any  of  the  nodes  (e?)  , 
the  sector  will  determine  if  the  trunk  or  circuit  is  contained  within  the  sector  boundaries 
©•  » not,  and  the  nodal  area  containing  the  station  responsible  for  manual  fault 
isolation  is  in  another  sector  , this  sector  will  inform  the  other  sector  that  no 
problem  was  found  . If  the  responsible  node  is  not  in  another  sector  (g)  , this 
sector  will  wait  for  the  results  from  the  other  sectors  involved  before  proceeding.  If 
the  other  sectors  did  not  find  a problem  , or  the  trunk  or  cir-ctrif  is  contained  with- 
in this  sector  , the  sector  will  inform  the  responsible  node  to  initiate  manual 
fault  isolation  procedures  . If  another  sector  did  find  a problem  ^7)  , this  sec- 
tor will  notify  all  of  the  appropriate  nodes  that  the  problem  has  been  isolated  to  another 
sector  . The  nodes  will  then  stop  any  associated  fault  isolation  that  was  in  pro- 
gress. 

If  one  of  the  nodes  does  reveal  a problem  Q , and  reports  that  the  problem  is 
contained  within  its  area  , the  sector  will  notify  the  other  nodes  involved  who 
will  cancel  their  associated  fault  isolation  . If  a problem  is  found,  but  no  node 
can  isolate  it  within  its  area  , all  of  the  information  from  the  nodes  is  displayed 
to  the  sector  controller  . The  controller  will  review  the  information  to  determine 
between  which  nodes  the  trouble  must  exist  (o)  . The  sector  will  then  instruct  the 
appropriate  notes  to  proceed  with  manual  fault  isolation  . 
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Figure  4. 1-1.  Sector  Level  Functional  Flowchart  (Sheet  2 of  3) 
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If  the  trunk  or  circuit  is  equipped  with  ATEC  at  any  of  the  nodes  , the 
sector  will  wait  for  the  results  from  ATEC  before  proceeding  ((j)  . The  sector  con- 
trol subsystem  (SCS)  of  ATEC  (IT)  , as  mentioned  previously,  functions  independely 
of  the  unified  control  information  flow.  If  ATEC  can  isolate  the  fault  , the  ATEC 
structure  informs  the  stations  involved  and  the  data  base  at  the  nodal  level  is  updated 
with  the  results.  If  ATEC  cannot  isolate  the  fault,  the  information  obtained  by  ATEC 
is  displayed  to  the  sector  controller  ^t)  who  must  decide  on  what  manual  actions 
should  be  taken  . Depending  upon  the  number  and  distribution  of  the  nodes  equip- 
ped with  ATEC,  the  controller  can  decide  to  either  direct  the  other  nodes  to  initiate 
a manual  level  check  (^d)  , or  instruct  the  responsible  node  to  initiate  manual  fault 
isolation  . 

Sheet  3 shows  the  reroute  implementation  routine  and  the  distribution  of  infor- 
mation that  is  received  from  the  ACOC  at  the  sector.  All  new  fault  indications  up- 
dating the  data  base  on  Sheet  1 enter  the  reroute  routine  at  S3-1.  The  sector  examines 
the  new  reports  for  three  criteria  which  must  be  met  to  automatically  initiate  reroute 
actions.  The  problem  must  be  an  outage  condition  , the  trunk  or  circuit  must 
have  a preassigned  reroute  (b)  , and  this  sector  must  be  designated  is  being  respon- 
sible for  establishing  the  reroute  (c^  . If  all  three  of  these  criteria  are  not  met  the 
sector  stops  the  reroute  routine  and  keeps  the  status  of  the  condition  for  information 
purposes  ©• 

If  the  conditions  are  met  for  initiating  reroute  actions,  the  sector  examines  the 
data  base  for  any  degraded  indications  which  may  have  been  reported  on  the  assigned 
reroute  path  (e)  . If  none  are  found,  the  reroute  path  and  the  information  on  the 
outage  is  displayed  to  the  sector  controller  who  must  determine  if  this  reroute 
should  be  implemented  (g)  . If  so,  the  appropriate  nodes  are  directed  to  initiate 
the  reroute  action  , and  the  sector  data  base  is  updated  to  include  the  fact  that 
the  reroute  has  been  ordered  . The  data  base  is  not  updated  to  include  the  im- 
plenentation  of  the  reroute  until  the  stations  involved  submit  an  update  report  saying 
that  the  reroute  is  established. 
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Figure  4.1-1.  Sector  Level  Functional  Flowchart  (Sheet  3 of  3) 
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If  the  trunk  or  circuit  being  rerouted  crosses  the  sector  boundary  (T)  , the 
other  sectors  involved  are  informed  of  the  reroute  action  . The  other  sector 
will  then  direct  its  node  involved  to  Implement  the  reroute.  The  ACOC  is  informed 
of  all  reroute  actions  taken  by  the  sector  . If  the  controller  decides  not  to 
implement  the  reroute  (G^  , the  status  of  the  fault  is  displayed  again  if  the  problem 
is  not  repaired  within  the  expected  time  period  (m)  . 

Information  from  other  sectors  directing  the  implementation  of  a reroute  , 
updates  the  data  base  to  indicate  the  reroute  has  been  ordered  . The  sector  then 
determines  which  nodes  are  involved  and  instructs  them  to  initiate  the  reroute  action 

® • 

If  the  sector  finds  that  the  preassigned  reroute  path  is  in  a degraded  or  outage 
condition  , the  information  concerning  the  outage  and  its  reroute  path  is  displayed 
to  the  sector  controller  . The  controller  can  then  decide  on  the  necessity  or 
possibility  of  initiating  reroute  actions  aside  from  the  preplanned  path  . 

The  sector  will  receive  direction  to  initiate  fault  isolation  or  reroutes,  and 
status  information  on  intertheater  links,  trunks,  and  circuits  from  the  ACOC  . 

If  it  is  status  information  , which  could  be  the  ACOC  placing  a circuit  in  a 
degraded  or  outage  condition  to  initiate  fault  isolation,  the  routine  on  Sheet  1 is  entered 
to  distribute  the  information  to  the  appropriate  locations.  If  the  ACOC  directs  a reroute 
© , the  sector's  reroute  routine  is  entered  and  the  ACOC  is  informed  of  the  action 
taken. 
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4.2  SECTOR  DATA  BASE  DESCRIPTION 

The  following  paragraphs  describe  the  Sector  level  data  base  in  terms  of  its 
structure,  content  and  sizing  requirements. 

4.2.1  Structure 

In  support  of  the  unified  control  effort  at  the  sector  level,  nine  data  files  were 
created.  These  files  include  Ssctor,  Node,  Station,  link,  Trunk  and  CCSD  masters, 
a fault  master  and  detail  and  a related  fault  detail.  Figure  4.  2-1  pictures  graphi- 
cally the  data  base  structure.  The  linkages  between  data  sets  indicate  that  the 
detail  data  set  can  be  accessed  through  master  record  parameters.  In  this  case,  a 
chain  of  fault  detail  records  can  be  retrieved  for  each  node,  responsible  station, 
link,  trunk,  CCSD  or  fault  ID  and  a chain  of  related  fault  records  can  be  read  for 
each  fault  ID. 

4.2.2  Content 

Tables  4.2-1  through  4. 2-9  describe  the  content  and  format  of  each  data  file 
within  the  Sector  level  data  base. 

The  connectivity  for  each  station,  link,  trunk  and  circuit  within  the  theatre  is 
provided  in  each  of  the  respective  master  data  files.  A status  summary  or  "degree 
of  degradation"  is  also  provided  in  these  files.  As  faults  are  reported  to  the  gector, 
these  status  files  are  updated  with  the  current  status.  The  detailed  fault  record, 
generated  from  a trouble  report,  is  added  to  the  Sector  data  base  of  the  responsible 
station.  Any  additional  trouble  reports  on  the  same  problem  will  cause  related 
fault  file  records  to  be  added  to  the  data  base  and  linked  to  the  detailed  fault  record. 

Finally,  directories  of  all  Nodes  under  a Sector  and  Stations  under  a Node  are 
provided  in  Sector  and  Node  data  files  respectively. 

4.2.3  Sizing 

The  sizing  estimates  for  the  Sector  level  data  base  are  summarized  in 
Table  4.2-10.  The  number  of  records  contained  within  each  data  file  was  based  on 
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the  station,  link,  trunk  and  CCSD  counts  for  the  European  theatre.  These  estimates 
were  then  increased  by  twenty  five  percent  to  allow  for  future  expansion.  In  sizing 
the  fault  files  the  number  of  faults  resident  in  the  Node  data  base  at  any  given  time 
was  estimated  to  be  thirty  percent  of  the  total  number  of  circuits.  This  figure  was 
based  on  a study  performed  by  Computer  Sciences*  in  February  1971  on  the  Automated 
Quality  Monitoring  Reporting  Subsystem  (AQMRS)  at  Coltano  Italy.  This  study  showed 
that  the  AQMRS  monitoring  function  identified  twenty  percent  of  the  circuits  monitored 
as  being  in  a degraded  condition.  Since  one  of  the  sources  for  fault  inputs  is  the  A TEC 
system,  which  is  considerably  more  powerful  than  the  AQMRS,  the  figure  of  thirty 
percent  was  chosen  for  sizing. 

The  resulting  disk  space  requirement  for  the  Sector  was  estimated  to  be 
approximately  6.3  megabytes. 


ti 

J 


* Evaluation  of  USASTRATCOM  Automated  Quality  Monitoring  Reporting  Subsystem 
(AQMRS),  SCCC-TED-71-FR-22,  Computer  Sciences  Corporation,  February  1971 
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SECTOR  DATA  BASE  STRUCTURE 


The  arrows  indicate  pointers  within  the  Data  File  records 
allowing  access  to  the  detail  or  subordinate  file  records. 

Figure  4.  2-1.  Sector  Data  Base  Structure 
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.TOTAL  = 100 


Table  4.  2-5.  Trunk  Master  Data  File  (Sheet  1 of  2) 
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Isolation  Flag  Cods  indicating  whether  or  not  the  fault  has  been  ASCII 

isolated. 


Table  4. 2-9.  Related  Fault  File 


2-10.  Sector  Level  Data  Base  Sizing 


RELATED  FAULT  DETA III  15  I 3,600  I 54,000  108,000 


4.3  SOFTWARE  CONSIDERATIONS  FOR  THE  SECTOR 


A preliminary  software  design  for  the  Sector  has  been  performed  using  the 
THREADS  design  methodology.  This  process  is  described  in  detail  in  Section  1.4. 

In  the  following  subsections  a detailed  software  design  for  the  Sector  level  of  unified 
control  is  presented  in  terms  of  the  THREADS  (identified  during  the  design  effort)  to 
support  the  functional  capabilities  discussed  in  Section  4.1. 

For  each  Sector  function  a THREAD  flow  diagram  which  describes  the  process- 
ing steps  required  in  accomplishing  the  function  and  the  routines  supporting  each 
processing  step  is  presented.  A sizing  analysis  is  then  provided  which  addresses 
individual  routine  size  requirements  as  well  as  overall  Sector  processing  system  size 
requirements  including  estimates  of  lines  of  code  and  memory  occupancy.  Processor 
memory  requirements  are  then  addressed  including  support  software,  resident  data 
structures  and  overlay  techniques.  A parametric  processing  load  analysis  is  provided 
which  shows  processor  and  disk  load  requirements  for  the  Sector  as  a function  of 
various  system  event  occurrence  rates.  Finally,  the  general  characteristics  of 
processor  support  software  as  they  pertain  to  the  Sector  level  of  unified  control  are 
discussed. 

4.3.1  Sector  Software  Design 

The  following  paragraphs  present  a software  system  design  for  the  Sector  in 
terms  of  52  Sector  level  THREADS.  These  THREADS  are  derived  from  the  Sector 
level  requirements  presented  in  Section  4.1,  where  each  THREAD  supports  a specific 
functional  requirement.  The  THREADS  are  first  presented  in  a hierarchical  structure 
which  shows  all  software  capabilities  available  to  each  functional  element  of  unified 
control  at  the  Sector  level.  Each  THREAD  is  additionally  described  in  a THREAD 
flow  diagram  which  shows  the  discrete  processing  requirements  and  individual  routines 
necessary  to  accomplish  the  prescribed  function.  Finally,  all  routines  identified  in 
the  THREAD  flow  diagrams  are  summarized  in  a hierarchical  computer  program 
structure  showing  the  various  levels  of  control  within  the  applications  software  system. 
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4. 3. 1.1  Sector  THREADS 


Figure  4.3-1  summarizes  the  THREADS  which  comprise  the  Sector  level  of 
unified  control.  The  figure  shows  a two-level  hierarchy  of  THREADS  supporting 
each  operational  element  serviced  by  the  Sector  including  the  Sector  Controller, 
other  Sectors,  Nodes,  and  the  ACOC. 

The  top  level  of  the  hierarchy  performs  I/O  and  preliminary  message  process- 
ing functions.  The  software  represented  by  these  THREADS  performs  line  handling, 
buffer  management,  and  task  scheduling  activities.  The  stimulus  to  these  THREADS 
is  generally  an  interrupt  or  other  condition  indicating  a call  for  input  or  output  service, 
while  the  response  is  a completed  I/O  operation  with  appropriate  subsequent  process- 
ing scheduled.  Each  subsequent  processing  task  is  supported  by  a distinct  THREAD 
located  on  the  second  level  of  the  hierarchy.  The  scheduling  activities  performed  by 
the  top  level  THREADS  serve  as  the  stimulii  to  the  various  second  level  THREADS. 

The  second  level  THREADS  are  grouped  into  four  subtrees  corresponding  to 
the  four  sources  of  external  stimulus  to  the  Sector.  These  groups  are  mapped  to  the 
top  level  THREAD  they  support  by  the  connectors  G through  J on  the  first  sheet  of  the 
figure.  To  examine  the  support  available  to  a given  Sector  element  it  is  necessary 
only  to  inspect  the  corresponding  subtree  for  that  element. 

The  THREADS  contained  in  Figure  4. 3-1  are  presented  in  an  abbreviated  format. 
In  the  next  paragraph  each  THREAD  will  be  expanded  into  a flow  diagram  in  order  to 
show  the  detailed  process!  ig  requirements  and  associated  software  requirements  to 
accomplish  the  function  supported  by  the  THREAD. 

4. 3. 1 . 2 THREAD  Flow  Diagrams 

Figures  4.3-3  through  4.3-7  show  the  detailed  flow  diagrams  for  the  Sector 
level  THREADS.  Each  figure  contains  the  diagrams  for  all  THREAD6  which  support 
a given  Sector  element.  Table  4.3-1  summarizes  the  contents  of  these  figures. 


The  basic  format  of  the  flow  diagram  is  shown  in  Figure  4.3-2.  The  stimulus 
and  response  information  will  be  the  same  as  indicated  in  the  abbreviated  formats 
used  in  the  THREAD  hierarchy.  However,  while  the  processing  information  is  sum- 
marized in  the  abbreviated  format,  it  is  expanded  into  a series  of  more  precise  steps 
in  the  flow  diagram.  Each  step  also  lists  the  computer  programs  necessary  to  support 
the  indicated  processing. 

The  supervisory  level  and  I/O  diagrams  are  shown  in  Figure  4.3-3,  These 
THREADS  divide  into  two  basic  types.  The  first  four  THREADS  address  input  process- 
ing of  data  from  each  unified  control  element  which  communicates  directly  with  the 
Sector.  In  addition  to  input  handling  functions  they  perform  supervisory  scheduling 
functions  based  on  the  message  types  that  are  received.  The  remaining  three  THREADS 
perform  communications  output  handling  for  the  ACOC,  Node,  and  Sector  interfaces. 

Figure  4.3-4  shows  the  THREAD  diagrams  which  provide  support  to  the  Sector 
Controller  position.  Many  of  the  requests  that  can  be  made  from  this  position  are 
identical  with  Node  and  Station  Controller  requests  and  utilize  common  software. 

Among  the  types  of  data  that  may  be  requested  are  media  status,  detailed  fault  record 
information,  connectivity,  journal  contents,  and  summaries  of  outstanding  faults.  The 
Sector  Controller  also  has  the  capability  to  update  fault  reports  as  a result  of  isolation 
activities  he  has  performed,  or  assign  responsibility  for  further  fault  isolation  to  the 
terminating  station  in  the  event  he  is  unsuccessful  from  the  controller  position  in  iso- 
lating a fault. 

During  the  course  of  fault  isolation  the  Controller  may  request  that  automated 
and/or  manual  fault  isolation  measurements  be  performed  and  reported  back  to  his 
position.  Additionally,  he  may  request  the  engagement  of  a reroute  plan.  This 
request  is  automatically  forwarded  to  the  ACOC  for  authorization  and  then  distri- 
buted to  the  implementing  stations. 

Figure  4.3-5  shows  the  Node  handling  software.  The  majority  of  the  messages 
received  from  the  Node  are  of  three  general  types:  responses  to  requests  for  data 
from  the  Node  and  Station  levels,  requests  to  supply  data  to  the  Node  and  Station  levels, 
and  fault  related  broadcast  messages. 
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Additional  messages  are  provided  for  maintaining  data  base  integrity  including 
connectivity  modification  and  reroute  confirmation  messages.  In  these  two  cases, 
the  data  base  is  not  updated  until  confirmation  of  the  modification  has  been  made  by 
the  responsible  element. 

Figure  4.3-6  shows  the  ACOC  handling  software.  In  addition  to  the  standard 
request  servicing  messages,  several  control  directive  messages  are  received  from 
the  ACOC.  These  messages  include  reroute  implementation  and  configuration  modi- 
fication directives  issued  by  the  ACOC  controller. 

The  Sector  message  handling  software  is  shown  in  Figure  4. 3-7.  All  of  the 
messages  supported  by  this  package  pertain  to  fault  broadcast  handling,  or  data 
request/response  movement. 

In  the  next  paragraph,  all  of  the  computer  programs  which  are  identified  in 
Figures  4. 3-3  through  4.3-7  are  presented  in  a computer  program  hierarchy  in  order 
to  show  the  relationships  of  the  various  routines  and  to  summarize  the  applications 
software  system  for  the  Sector. 

4. 3. 1.3  Computer  Program  Hierarchy 

All  of  the  routines  which  are  identified  in  the  Sector  level  THREADS  have  been 
structured  into  a six-level  program  hierarchy.  In  determining  the  appropriate  level 
for  a given  routine,  two  guidelines  are  followed.  First,  a given  routine  may  call  only 

j 

those  routines  which  reside  at  lower  hierarchical  levels.  The  application  of  this  rule 
ensures  that  the  levels  of  the  hierarchy  indicate  the  various  levels  of  control  within 
the  software  system.  Second,  each  level  of  the  hierarchy  should  be  functionally  homo- 
geneous. That  is,  routines  which  perform  similar  functions  should  be  grouped  at  a 
given  hierarchical  level. 

Figure  4.3-8  shows  the  program  hierarchy  for  the  Sector  level  of  unified  control. 

The  top  level  of  the  hierarchy  contains  the  Sector  SUPERVISOR  which  controls 
execution  of  all  scheduled  events  in  the  software  system. 

I 
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The  second  level  contains  the  interrupt  driven  I/O  drivers  and  a series  of 
message  processors.  Each  message  processor  controls  the  support  activities  for 
one  of  the  major  input  sources  at  the  Sector.  In  general,  these  routines  supervise 
message  decoding/ validation  and  perform  overlay  retrieval. 

The  third  level  of  the  hierarchy  contains  the  routines  responsible  for  perform- 
ing major  operational  functions.  Such  functions  include  processing  individual  Controller, 
Sector,  Node,  and  ACOC  message  types. 

The  fourth  level  provides  significant  support  functions  to  the  various  third  level 
routines.  For  example,  the  third  level  Sector  CONNECTIVITY  DISPLAY  PROCESSOR 
depends  heavily  on  the  four  connectivity  RETRIEVAL  routines  on  this  level.  This 
amount  of  functional  support  minimizes  duplication  of  software  between  the  various 
operational  function  routines  on  the  third  level.  In  addition,  it  provides  a level  of 
insulation  between  the  functionally  oriented  routines  in  the  upper  levels  and  the  various 
data  base  structures  employed  in  the  lower  levels  of  the  hierarchy. 

The  fifth  level  consists  largely  of  file  managers  for  the  various  components  of 
the  data  base.  These  file  managers  rely  heavily  on  the  sixth  level  generic  data  base 
management  support  routines  FIND,  GET,  CREATE,  DELETE  and  MODIFY  for  access 
to  the  various  files.  Additional  system  support  activities  supplied  on  the  sixth  level 
include  error  processing,  message  type  decoding  and  I/O  buffer  management. 

4.3.2  Software  Sizing 

The  following  two  paragraphs  present  a software  sizing  analysis  for  the  Sector. 

In  the  first  paragraph,  each  routine  identified  during  the  design  effort  is  addressed  in 
terms  of  estimated  lines  of  code  and  program  and  data  occupancy  requirements.  The 
second  paragraph  then  presents  Sector  processor  memory  requirements  based  on  a 
two-level  overlay  structure. 

4. 3.2.1  Program  Sizing 

The  sizing  of  the  programs  presented  in  this  paragraph  is  based  on  an  estima- 
tion of  the  number  of  lines  of  HOL  code  required  to  implement  each  routine  in  the 
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Sector  program  hierarchy  (Paragraph  4. 3. 1.3),  plus  additional  memory  required  to 
accommodate  data  for  each  routine.  This  sizing  includes  applications  software  and 
operating  system  enhancements  only  and  assumes  that  the  host  computer  supplies 
support  software  capabilities  as  described  in  4.3.4. 

Table  4.3-2  summarizes  the  program  sizing  for  the  Sector.  The  program 
occupancy  for  each  routine  is  based  on  an  expansion  factor  of  15  bytes  of  storage  for 
each  line  of  HOL.  This  ratio  is  typical  of  16-bit  word  length  machines  using  currently 
available  HOL  compilers.  Further  justification  of  this  expansion  ratio  is  provided  in 
Section  1.4.  Where  applicable,  the  data  occupancy  for  each  routine  includes  buffer 
and  table  space  requirements.  Without  the  use  of  overlays,  the  total  memory  require- 
ment for  the  Sector  applications  software  is  192K  bytes. 

4. 3. 2. 2 Processor  Memory  Requirements 

The  software  system  described  in  Section  4.3.1  is  functionally  partitionable  and 
is  susceptible  to  incorporation  into  an  overlay  structure.  The  use  of  overlays,  where 
on-line  secondary  storage  capabilities  are  available,  minimizes  processor  memory 
requirements  by  retaining  low  demand  software  in  secondary  storage. 

An  overlay  structure  for  the  Sector  software  was  developed  by  dividing  the 
routines  contained  in  the  Sector  program  hierarchy  into  three  categories:  resident, 
element  support  and  functional  support. 

The  resident  routines  are  high  demand  routines  which  support  supervisor/control 
of  all  processing  functions.  Such  routines  as  the  SECTOR  SUPERVISOR,  the  I/O  drivers, 
the  generic  data  base  access  routines,  buffer  managers,  display  handlers,  and  the 
destination  processors  are  considered  in  this  category  since  they  are  used  to  support 
multiple  elements  and  many  of  the  functional  routines.  Table  4.3-3  summarizes  the 
resident  routines  for  the  Sector.  These  routines  require  78, 425  bytes  of  memory. 

The  routines  which  compose  the  support  overlay  are  also  summarized  in  Table 
4.3-3  according  to  the  operational  element  which  they  support.  The  positions  and 
their  respective  support  sizes  are  summarized  below: 
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Sector  Controller  Support  9, 000  bytes 

Sector  Support  7, 875  bytes 

. ACOC  Support  12,375  bytes 

Node  Support  10, 875  bytes 

The  routines  which  are  used  for  supporting  an  operational  element  are  defined 
to  be  those  routines  that  would  be  needed  by  any  of  the  functional  routines  supporting 
the  given  element. 

The  routines  comprising  the  functional  overlays  for  the  Sector  Controller, 

Sector,  ACOC,  and  Node  are  summarized  in  Table  4.3-4.  Depending  on  die  function 
to  be  performed,  only  one  of  these  overlays  would  be  in  memory  at  any  time. 

In  order  to  determine  the  amount  of  memory  required  at  the  Sector  for  applica- 
tions software,  it  is  necessary  to  add  the  memory  requirements  for  the  resident 
routines,  support  overlay  routines  and  the  largest  functional  overlay  module  for  each 
Sector  element.  Table  4.3-5  shows  that  the  largest  memory  requirement  occurs  for 
processing  Node  input.  In  this  case  the  applications  software  requires  111,  800  bytes 
of  main  memory. 

In  addition  to  the  applications  software  requirements,  the  processor  memory 
must  accommodate  the  resident  portion  of  a disk-based  operating  system.  Based  upon 
currently  available  real-time  operating  system  software,  a residency  requirement  for 
an  operating  system  providing  the  support  outlined  in  Section  3.3.4  is  12, 000  bytes. 

This  does  not  include  occupancy  within  the  operating  system  for  the  I/O  drivers  and 
buffer  areas  which  were  sized  as  part  of  the  applications  software.  The  total  Sector 
memory  requirements  is  now  determined  to  be  124K  bytes. 

4.3.3  Sector  Processing  Load 

A worst  case  sustained  load  analysis  for  the  Sector  is  presented  in  this  paragraph. 
Both  processor  and  disk  utilizations  are  considered  because  of  the  large  amount  of  data 
base  access  activity  required  to  support  unified  control  functions.  The  utilizations  are 
parametrically  derived  and  presented  in  a series  of  curves  which  show  utilization  as  a 
function  of  the  rate  of  Node,  Sector,  and  ACOC  fault  notification. 
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Table  4.3-6  summarizes  the  set  of  worst  case  algorithms  on  which  the  load 
analysis  is  based.  Each  algorithm  is  analyzed  for  the  number  of  assembly  language 
instructions  executed  and  the  number  of  disk  accesses  performed  for  a single  execu- 
tion of  the  algorithm.  The  flowcharts  and  detailed  analysis  of  these  algorithms  are 
contained  in  Appendix  A to  this  report. 

Algorithms  SI,  S2  and  S3  perform  fault  notification  broadcast  processing  for 
messages  received  from  other  Sectors,  the  ACOC,  and  Nodes  respectively.  Algorithm 
S4  is  the  worst  case  display  request  that  can  be  made  from  the  Sector  Controller  posi- 
tion. This  algorithm  will  be  used  later  in  this  paragraph  to  establish  average  and 
worst  case  operator  response  times. 

Table  4. 3-7  shows  the  derivation  of  the  worst  case  I/O  support  load.  For  each 
element  interfaced  at  the  Sector  the  maximum  aggregate  bandwidth  is  computed  in 
terms  of  the  number  of  assembly  level  instructions  required  per  second  to  effect  the 
I/O  transfers.  For  the  worst  case  it  is  assumed  that  data  will  be  passed  a character 
at  a time  on  the  processor  I/O  bus.  From  this  table  the  I/O  load  at  the  Sector  is 
18,900  instructions/sec. 

Figure  4.3-9  presents  the  derivation  of  the  processing  load  at  the  Sector. 

From  Equation  (1)  it  is  seen  that  the  total  processing  load  is  the  sum  of  the  loads 
supporting  Node  (PNODE).  Sector  (pSECTOR)»  and  ACOC  (PACOC)  fault  notifications, 
cycle  stealing  due  to  disk  DMA  operation  (pD|gK)  311(1  communications  I/O  (Pj/q)» 
Equation  (2)  shows  that  the  fault  notification  processing  loads  are  the  produces  of  the 
single  occurrence  loads  and  occurrence  rates.  Equations  (3),  (4)  and  (5)  show  the 
computation  of  the  single  occurrence  loads  for  Node,  Sector,  and  ACOC  fault  notifica- 
tion respectively.  Since  the  sustained  load  will  be  computed  for  a one  minute  interval, 
a time  conversion  factor  must  be  included  to  find  the  effective  average  second  load. 
Equation  (6)  accounts  for  memory  cycle  stealing  due  to  the  disk  DMA  activity.  An 
average  disk  access  size  of  one  256  word  block  is  assumed.  Equation  (7)  shows  the 
communications  I/O  load.  The  worst  case  I/O  load  as  presented  in  Table  4.3-7  is 
assumed.  By  rewriting  Equation  (2),  Equation  (8)  now  shows  the  Sector  processing 
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load  as  a function  of  the  rate  of  fault  notification  from  the  other  system  elements. 
Tlois  equation  is  plotted  in  Figure  4.3-10  for  values  of  from  0 to  60,  R 


from  0 to  20,  and  RAr,„„  from  0 to  20. 
ACOC 


from  0 to  60,  R 
NODE  ’ SECTOR 


Figure  4.3-11  shows  the  derivation  of  the  disk  load  at  the  Sector.  Equation  (1) 
shows  that  the  total  disk  load  is  the  sum  of  the  disk  loads  supporting  fault  notification 
processing  for  the  Node,  Sector,  and  ACOC  elements.  These  quantities  are  a function 
of  the  rate  of  fault  related  event  occurrence  as  shown  in  Equation  (2).  Equation  (6) 
shows  the  total  disk  load  as  a function  of  these  occurrence  rates.  Figure  4.3-12 

plots  Dg  as  a function  of  RNODE*  RSECTOR’  and  RACOC*  The  100  1561:06111  utiliza" 
tion  line  for  a typical  moving  head  disk  with  sufficient  capacity  to  accommodate  the 
Sector  data  base  is  also  indicated  on  this  figure.  The  utilization  threshold  is  based 
on  a 50  millisecond  average  access  time. 

It  is  seen  from  the  projected  processor  and  disk  loads  that  the  nature  of  unified 
control  processing  at  the  Sector  is  highly  I/O  bound.  Disk  utilization  is  therefore  the 
critical  factor  in  accommodating  a worst  case  situation. 

Consider  the  case  where  the  following  unique  faults  are  reported  from  the  station 
level  at  an  average  Node  within  a one  minute  period: 


ATEC 
Stations 
Switch  Faults 


8 (assume  8 stations  at  average  Node) 
_2 
15 


Assuming  five  Nodes  within  the  Sector  area  this  amounts  to  75  faults  during  the 

worst  case  minute.  Assume  further  that  60  percent  of  these  faults  are  unique  and 

require  reporting  to  the  sector.  This  presents  a Node  fault  notification  rate  (Rxt/_ __) 

NODE 

of  45  faults/minute.  At  this  rate  up  to  20  Sector  fault  notifications  and  5 ACOC  noti- 
fications can  be  received  before  disk  saturation  occurs  for  a 50  millisecond  average 
access  time  device. 

The  average  load  on  the  Sector  processor  and  disk  is  considerably  less  since  the 
words  case  Node  fault  rate  discussed  above  could  not  be  sustained  in  view  of  the  average 
daily  fault  rate  experienced  in  Europe. 
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Algorithm  S4  can  be  used  to  determine  operator  response  times  as  a function  of 
the  relative  load  on  the  Sector  processor  and  disk.  The  algorithm  requires  that  18, 012 
instructions  and  16  disk  accesses  be  performed.  The  response  time  will  be  dominated 
by  disk  access  time.  The  disk  activity,  assuming  no  contention  for  disk  resources 
would  require  800  milliseconds  (16  accesses  @ 50  milliseconds/access). 

Assuming  a relatively  slow  processing  capability  (8  microsecond  average 
instruction  time)  the  processing  would  require  144  milliseconds  (no  contention). 

The  total  time  until  the  connectivity  request  processing  is  completed  and  the 
data  is  ready  for  display  is  then  . 944  seconds  when  no  other  activity  is  ongoing. 

Assuming  that  the  Sector  is  processing  45  Node  level,  20  Sector  level,  and  5 
ACOC  level  fault  notifications  the  response  time  for  this  request  then  degrades  to 
2.16  seconds  (1.80  seconds  total  for  disk,  .360  seconds  for  processing). 

4.3.4  Support  Software 

The  operational  and  development  software  capabilities  required  to  support 
Sector  processing  functions  are  similar  to  the  capabilities  described  for  the  Node. 

This  similarity  is  due  to  the  high  degree  of  functional  commonality  between  all  levels 
of  unified  control.  For  a description  of  the  support  software  requirements  see 
Section  3.3.4. 
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Figure  4.3-1.  Sector  Threads  (Sheet  2 of  5) 


Figure  4.3-1.  Sector  Threads  (Sheet  4 of  5) 
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Figure  4.3-3.  Supervisory  and  I/O  Level  THREADS  (Sheet  2 of  2) 


Figure  4.3-5.  Node  — ► Sector  THREAD  Diagrams  (Sheet  2 of  6) 
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Figure  4.3-6.  ACOC— ►Sector  THREAD  Diagrams  (Sheet  2 of  3) 


Figure  4.3-7.  Sector  — ► Sector  THREAD  Diagrams  (Sheet  1 of  4) 
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Figure  4. 3-8.  Computer  Program  Hierarchy 
for  the  Sector 
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Sector  Processing  Load: 


P=P  +P  +P  +P  +P 

S NODE  SECTOR  ACOC  DISK  I/O 

ps  = lnode  rnode  + lsector  rsector  + lacoc  racoc  + 

p + p 

DISK  I/O 


where 


lnode  = (Inode)  (Time  conversion> 

MIN 

~ (IS3)  (SEC  ) 

= (2768) (1/60) 

= 46.13 


L =,I  v ,M2L 

SECTOR  'Tfl'  'SEC  ' 

= (2288)  (1/60) 

= 38.13 


f 


L — /t  v ,MI*L 

ACOC  ' N2*  'SEC  ’ 

= (2288)  (1/60) 

= 38.13 


P^TC,„  = 256  D„ 
DISK  S 


where 


D = Disk  Load  (see  Figure  4.3-11) 
b 

P^Q  = 18,900  (see  Table  4.3-7) 


ps  = 46‘ 13  rnode  + 38‘ 13  rsector  + 38- 13  racoc  + 256  Ds  + 18’ 900  (8) 


Figure  4.3-9.  Derivation  of  the  Sector  Processing  Load 
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Figure  4.3-10  (Sheet  1).  Sector  Processing  Load 
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Sector  Disk  Load: 
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Figure  4.3-11.  Derivation  of  the  Sector  Disk  Load 


Figure  4.3-12  (Sheet  1).  Sector  Disk  Load  (R 
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SECTOR 


Figure  4.3-12  (Sheet  3).  Sector  Disk  Load  (R  = 10) 
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Table  4. 3-1.  Guide  to  Sector  Level  Detailed  THREAD  Diagrams 


Figure  Containing  Detailed 
Flow  Diagrams 
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Table  4.3-2.  Sector  Sizing  Summary  (Sheet  1 of  3) 
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Table  4.3-2.  Sector  Sizing  Summary  (Sheet  3 of  3) 
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Sector  Resident  and  Support  Overlay  Sizing  Summary  (Sheet  1 of  2) 


Table  4.3-3.  Sector  Resident  and  Support  Overlay  Sizing  Summary  (Sheet  2 of  2) 


Sector  Functional  Overlay  Structure  Sizing  Summary  (Sheet 


Table  4.3-4.  Sector  Functional  Overlay  Structure  Sizing  Summary  (Sheet  2 of  6) 
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Table  4.3-5.  Determination  of  the  Largest  Memory  Requirement 

for  the  Sector 


Table  4. 3-6.  Summary  of  Algorithms  for  the  Sector 


Algorithm 

Function 

# ASM 
Inst 

# Disk 

Accesses 

..  1 

SI 

Process  Fault  Notification  Broadcast 

* * j 

from  Sectors 

2288 

17 

S2 

Process  Fault  Notification  Broadcast 

from  ACOC 

2288 

17 

• l ] 

S3 

Process  Fault  Notification  Broadcast 

"7 

from  Nodes 

2768 

17 

u 

S4 

Sector  Controller  Request  for  CCSD 

j 

Connectivity  Display 

18012 

16 

i 


Table  4. 3-7.  Sector  I/O  Load 


4.4  HARDWARE  CONSIDERATIONS  FOR  THE  SECTOR 


In  the  following  subsections  the  hardware  considerations  for  the  Sector  level  of 
unified  control  including  processor,  peripheral  equipment,  and  processor  interface 
characteristics  are  addressed. 

4.4.1  Sector  Processor 

The  Sector  processing  system  as  described  in  Section  4.3  primarily  performs 
data  base  management  and  display  processing  functions.  A basic  characteristic  of 
such  functions  is  that  they  are  highly  I/O  bound  by  disk  and  terminal  access  require- 
ments as  demonstrated  by  the  load  analysis  presented  in  Paragraph  4.3.3.  In  addition, 
the  Sector  performs  message  routing  for  messages  defined  for  other  system  elements. 
Assuming  the  Sector  software  to  be  implemented  in  a multi-programmed  environment, 
a task  switching  overhead  may  be  applied  in  a manner  similar  to  that  presented  in 
Paragraph  3.4. 1 for  the  Node.  Using  an  estimate  of  1 millisecond/switch  the  Sector 
task  overhead  is  determined  to  be  70  milliseconds  (70  fault  notifications  @ 1 millisecond/ 
switch).  The  sustained  Sector  load  is  presented  for  three  classes  of  16-bit  word  length 
minicomputers  below: 

8 microsecond  average  instruction  time  - 0.217 

5 microsecond  average  instruction  time  - 0.136 

2.5  microsecond  average  instruction  time  - 0.069 

The  relatively  low  bandwidth  of  processing  requirements  at  the  Sector  is  apparent 
from  this  data.  At  these  bandwidths,  although  the  Sector  is  more  heavily  loaded  than 
the  Node,  processor  speed  is  not  a critical  factor  In  performing  real  time  functions. 

The  processor  memory  requirement  for  the  Sector  is  estimated  to  be  124K  bytes 
(Paragraph  4.3.2).  The  Sector  processor  should  at  a minimum  support  a memory 
configuration  adequate  to  satisfy  this  requirement  and  should  provide  for  future  memory 
growth  of  100%  to  allow  for  functional  expansion  of  Sector  capabilities. 

The  general  hardware  and  support  software  considerations  discussed  in 
Paragraph  3.4. 1 for  the  Node  apply  to  the  Sector  level  of  unified  control  as  well,  due 
to  the  functional  similarities  between  the  two  elements. 


4.4.2  Sector  Peripherals  and  Interfaces 


Figure  4.4-1  shows  the  hardware  configuration  for  the  Sector  which  includes  a 
processor  configured  with  a minimum  of  128K  bytes  of  main  memory,  10M  bytes  of 
random  access  disk  storage  for  data  base  and  program  overlay  storage,  a magnetic 
tape  unit  for  long  term  journal  retention,  and  as  many  as  two  KB/CRT  terminals  with 
local  hard  copy  capabilities  to  support  Sector  Controller  positions.  Communications 
between  the  ACOC  and  Nodes  and  the  Sector  are  provided  by  a total  of  10  2400  bps 
serial  synchronous  data  channels. 

The  data  base  storage  requirement  at  the  Sector  is  estimated  to  be  6.3M  bytes 
(Section  4.2).  In  order  to  provide  adequate  space  for  applications  and  support  soft- 
ware a disk  capacity  no  less  than  10M  bytes  should  be  supplied.  Because  of  the  high 
disk  utilization  at  the  Sector,  the  average  access  time  for  the  device  should  be  less 
than  50  milliseconds. 

The  magnetic  tape  unit  should  be  compatible  with  the  Node  and  ACOC  tape  units 
to  minimize  logistic  and  maintenance  related  costs.  Further,  the  compatability  would 
allow  batch  reduction  of  journal  data  to  be  accomplished  in  a single  facility  for  the 
entire  system. 

The  highly  interactive  nature  of  Sector  Controller  activity  requires  that  a power- 
ful KB/CRT  terminal  be  used  to  support  this  position.  The  required  capabilities  of 
this  terminal  are  the  same  as  those  described  for  the  Node  terminals  (Paragraph  3.4.2). 

In  order  to  provide  compatability  among  all  internal  unified  control  communi- 
cations interfaces,  the  synchronous  channels  for  the  Sector  should  have  the  same 
capabilities  as  the  channels  described  for  use  at  the  Node  (Paragraph  3.4.2). 


Up  to  4 - 2400  | 
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Figure  4.4-1.  Sector  Hardware  Configuration 
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SECTION  5 - ACOC  REQUIREMENTS 

| 

5.1  FUNCTIONAL  DESCRIPTION 

This  functional  description  encompasses  the  function  performed  at  the  ACOC 
level  of  the  unified  control  system.  In  the  detailed  flowcharts  that  follow  many  con- 
nections between  pages  were  required  because  of  the  complexity  of  the  diagrams.  A 
continuation  to  or  from  a different  page  is  shown  by  a circle  with  a number  in  it.  The 
numbering  system  is  the  same  as  that  used  on  the  general  flowchart.  If  a circle  con- 
tains A3-1  the  flow  continues  on  Sheet  3 of  the  ACOC  level  flowchart,  the  second 
number  distingishing  different  inputs  on  the  same  page.  A single  circle  indicates  the 
flow  is  information  only,  and  two  concentric  circles  indicates  that  the  flow  is  control 
and  direction  as  well  as  information. 

The  majority  of  the  functions  illustrated  within  the  ACOC  level  are  envisioned 
as  being  automatically  processed.  At  several  points,  however,  operator  intervention 
is  required.  This  is  indicated  within  the  flowcharts  by  the  dashed  lines. 


Figure  5.1-1  is  the  functional  flowchart  for  the  ACOC.  Sheet  1 shows  the  in- 
formation flow  at  the  ACOC  of  the  combined  system  status  received  from  the  sectors. 
This  information  updates  the  data  base  ^a)  , along  with  inputs  entered  by  the  SATCOM 
controller  concerning  satellite  link  problems  (b)  . If  the  report  is  on  a hazardous 
condition  at  a station  , the  information  will  be  displayed  to  the  network  controller 
a 8 it  is  received  . 

The  ACOC  will  determine  if  the  report  could  affect  any  links,  trunks,  or  circuits 
outside  of  the  theater  © . If  so,  the  other  theater  involved  will  be  informed  of  the 
problem  . Next,  the  ACOC  will  determine  if  the  fault  could  affect  any  AUTODIN 
IST's  or  access  lines  . If  this  is  possible,  the  status  information  is  displayed 
to  the  AUTODIN  controller  ^h)  to  assist  in  making  control  decisions  as  described 
on  Sheet  2.  The  report  is  then  examined  to  identify  any  AUTOVON  1ST  groups  or 
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special  lines  that  may  be  affected  ^T)  . If  any  are,  the  status  is  displayed  to  the 
AUTOVON  controller  © , as  for  AUTODIN,  to  give  the  controller  the  current  cir- 
cuit status  to  help  make  the  most  appropriate  control  decisions. 

Problems  reported  on  links,  trunks,  or  circuits  of  special  interest  to  the  ACOC 
are  automatically  displayed  to  the  network  controller  (k^  . The  controller  can  review 
the  information  and  direct  the  sectors  to  implement  a reroute  (m)  , if  they  have 
not  already  done  so.  The  sectors  inform  the  ACOC  of  all  reroute  actions  taken  ^n)  , 
and  the  network  controller  is  kept  informed  of  reroutes  by  receiving  displays  of  the 
information  when  it  is  reported  . The  status  of  all  reroute  actions  is  stored  in 
the  data  base  (&)  and  is  available  to  the  controller  upon  request. 

Information  is  received  at  the  ACOC  from  other  theaters  on  the  status  of  inter- 
theater links,  trunks,  and  circuits  (q)  . This  information  updates  the  data  base 
(R)  and  is  distributed  to  the  appropriate  sector  . The  routine  is  also  entered 
to  determine  if  AUTODIN  or  AUTOVON  could  be  affected  and  to  display  the  status  to 
the  controllers  as  required. 

Switch  alarms  and  local  subscriber  status  received  from  AUTOSEVOCOM  switch 
stations  is  stored  within  the  ACOC  data  base  ^T)  . Displays  are  presented  as 
reports  are  received  to  keep  the  network  controller  aware  of  the  status  of  the  switch 
stations  ^v)  . Serious  outage  conditions  would  prompt  the  controller  to  investigate 
possible  restoral  actions.  The  controller  will  also  be  capable  of  requesting  status 
information  from  the  data  base  to  assist  in  responding  to  inquiries  from  users  about 
service  degradations. 

Sheet  2 of  the  flowchart  shows  the  information  flow  from  the  AUTODIN  switch 
station  inputs.  AUTODIN  switch  alarm  indications  ® are  stored  in  the  data  base 

. Major  equipment  problems,  affecting  switch  throughput,  are  displayed  to  the 
AUTODIN  controller  (C^)  . 


Periodic  system  status  summaries  from  the  switch  stations  l^D^  are  stored  in 
the  ACOC  data  base  . Only  the  most  recent  system  STAT  is  kept.  When  a new 
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Figure  5. 1-1.  ACOC  Level  Functional  Flowchart  (Sheet  2 of  3) 
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report  is  received,  the  old  data  is  journaled.  After  each  new  summary  STAT  is 
received,  the  queue  lengths  on  each  channel  are  scanned  for  any  that 
exceed  the  thresholds  established  by  the  A COCv^^  . Any  channel  above  a threshold 
is  immediately  displayed  to  the  controller.  Other  STAT  reports  from  the  switches 
are  journaled  as  they  are  received. 

The  periodic  traffic  data  stored  within  the  data  base  will  normally  be  displayed 
upon  request  from  the  controller.  Any  traffic  data  that  has  been  sent  to  the  ACOC 
because  of  an  abnormal  condition  will  be  displayed  upon  receipt,  as  will  data  requested 
from  the  stations  by  the  AUTODIN  controller  . 

This  information  being  presented,  along  with  the  current  combined  system 
status  that  is  being  displayed  (from  Sheet  1)  allows  the  AUTODIN  controller  to  make 
traffic  control  decisions  knowing  the  current  status  of  switches,  IST's,  and  access 
lines  . The  controller  can  also  direct  the  transmission  system  to  implement  a 
reroute  to  alleviate  a traffic  backlog  condition  on  a degraded  circuit  ©•  Requests 
can  be  made  of  the  switch  station  for  more  traffic  information  , and  the  controller 
will  instruct  the  switch  stations  to  implement  traffic  control  actions  . Control 
actions  that  are  implemented  will  be  stored  in  the  data  base  © and,  as  the  controls 
arc  deleted,  the  entries  will  be  removed  from  the  data  base  and  entered  into  a journal 
record  . 

Sheet  3 shows  the  information  flow’  from  the  AUTOVON  switch  stations.  Equipment 
status  and  call  processing  data  reduced  at  the  switch  stations  are  received  and 
stored  in  the  ACOC  data  base  . This  information  from  all  of  the  switch  stations 
is  evaluated  further  and  any  abnormal  condition  affecting  network  performance 
will  be  displayed  to  the  controller  ^5)  , along  with  suggested  control  actions  to  help 
alleviate  the  problem.  This  information  being  presented,  along  with  the  current 
combined  system  status  that  is  being  displayed  (from  Sheet  1)  allows  the  AUTOVON 
controller  to  make  traffic  control  decisions  knowing  the  current  status  of  switches 
IST's,  and  special  interest  circuits  . 
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Figure  5.1-1.  ACOC  Level  Functional  Flowchart  (Sheet  3of  3) 


The  controller  can  direct  the  transmission  system  to  implement  reroutes  to 
alleviate  traffic  congestion  due  to  a degraded  trunk  group  (h)  . The  controller  can 
also  direct  the  sector  to  initiate  transmission  fault  isolation  if  required  and  not  already 
in  progress  ^f)  . Requests  can  be  made  of  the  switch  station  for  more  status  infor- 
mation if  required  (g^  , and  the  controller  will  implement  traffic  control  actions(7). 
Control  actions  that  are  implemented  will  be  stored  in  the  data  base  and  will  be 
displayed  to  keep  the  controller  aware  of  the  current  network  configuration.  As 
control  actions  are  deleted,  the  data  base  will  be  updated  , and  the  information 
will  be  entered  into  a journal  record  . 
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5.2  ACOC  DATA  BASE  DESCRIPTION 

The  following  paragraphs  describe  the  ACOC  level  data  base  in  terms  of  its 
structure,  content  and  sizing  requirements. 

5.2.1  Structure 

In  support  of  the  unified  control  effort  at  the  ACOC  level,  sixteen  data  files 

were  created.  These  files  include  Sector,  Npde,  Station,  Link,  Trunk  and  CCSD 

/ 

masters,  a fault  master  and  a related  fault  ^detail,  AUTODIN  and  AUTOSEVOCOM 

/ 

station  details,  and  five  AUTOVON  files.  ^Figure  5.2-1  pictures  graphically  the 
data  base  structure.  The  linkages  among  data  sets  indicate  that  the  detail  data  set 
records  can  be  accessed  through  master  record  pointers.  In  this  case,  a chain  of 
fault  detail  records  can  be  retrieved  for  each  Node,  responsible  station,  link,  trunk, 
CCSD  or  fault  ID  and  chains  of  related  fault  records  can  be  read  for  each  fault  ID. 

In  addition,  station  status  and  traffic  detail  records  can  be  accessed  through  the 
station  master  pointers. 

5.2.2  Content 

Tables  5.  2-1  through  5.  2-16  describe  the  content  and  format  of  each  data  file 
within  the  ACOC  level  data  base. 

The  connectivity  for  each  station,  link,  trunk  and  circuit  within  the  theater  is 
provided  in  each  of  the  respective  master  data  files.  A status  summary  or  "degree 
of  degradation"  is  also  provided  in  these  files.  As  faults  on  link,  trunk  and  special 
circuits  are  reported  to  the  ACOC,  these  status  files  are  updated  with  the  current 
status.  The  detailed  fault  record,  generated  from  a trouble  report,  is  added  to  the 
ACOC  data  base.  Any  additional  trouble  reports  on  the  same  problem  will  cause 
related  fault  file  records  to  be  added  to  the  data  base  and  linked  to  the  detailed  fault 
record. 

Equipment  status  and  traffic  trouble  indicators  are  provided  in  the  five 
AUTOVON  files  which  basically  maintain  status  of  out-of-threshold  conditions  as 
determined  at  the  AUTOVON  switch  station  level  module. 
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Finally,  directories  of  all  nodes  under  a sector  and  station  under  a node  are 
provided  in  sector  and  node  data  files  respectively. 

5.2.3  Sizing 

The  sizing  estimates  for  the  ACOC  level  data  base  are  summarized  in  Table 
5.2-17.  The  number  of  records  contained  within  each  file  was  based  on  the  station, 
link,  trunk  and  CCSD  counts  for  the  European  theater.  These  estimates  were  then 
increased  by  twenty  five  percent  to  allow  for  possible  expansion.  The  number  of 
records  contained  within  the  AUTOVON  detail  files  was  based  on  the  number  of  trunk 
groups  and  trunks  in  the  European  theater. 

In  sizing  the  fault  files,  the  number  of  faults  resident  in  the  node  data  base  at 
any  given  time  was  estimated  to  be  thirty  percent  of  the  total  number  of  circuits. 
This  figure  was  based  on  a study  performed  by  Computer  Sciences*  in  February  1971 
on  the  Automated  Quality  Monitoring  Reporting  Subsystem  (AQMRS)  at  Coltano  Italy. 
This  study  showed  that  the  AQMRS  monitoring  function  identified  twenty  percent  of 
the  circuits  monitored  as  being  in  a degraded  condition.  Since  one  of  the  sources 
for  fault  inputs  is  the  ATEC  system  which  is  considerably  more  powerful  than  the 
AQMRS,  the  figure  of  thirty  percent  was  chosen  for  sizing. 

The  resulting  disk  space  requirements  for  the  ACOC  was  estimated  to  be 
approximately  6.7  megabytes. 


♦Evaluation  of  USASTRATCOM  Automated  Quality  Monitoring  Reporting  Subsystem 
(AQMRS),  SCCC-TED-71-FR-22,  Computer  Sciences  Corporation,  February  1971 


ACOC  DATA  BASE  STRUCTURE 


Table  5. 2-2.  Node  Master  Data  File 


Total  = 51 


Station  Detail  Switch  Status  Detail  File  (if  applicable). 


Table  5. 2-4.  Link  Master  Data  File 


TOTAL  =100 
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Table  5. 2-8.  Fault  Detail  Data  File  (Sheet  1 of  3) 


Pointer  that  is  associated  with  the  given  trunk  number  (if 

applicable). 

Fault  Detail  Pointer  to  the  next  record  in  the  Fault  Detail  Data  file  Integer 

Pointer  that  is  associated  with  the  given  circuit  number  (if 

applicable). 


Table  5.  2-8.  Fault  Detail  Data  File  (Sheet  3 of  3) 
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TOTAL  = 15 


Table  5.  2-10.  AUTODIN  Switch/Traffic  Status  Detail  Data  File 


* Equipment  codes  can  be  found  in  DCA  310-55-1, 

Section  8. 

**  Refer  to  DCAC  310-D70-30  for  line  formats.  Total  * 1,979 
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TCMF  Receiver  An  indicator  of  the  number  of  busy  TCMF  Receivers  BCD 

Overload  Indicator  exceeding  a threshold  and  time  the  threshold  was 

exceeded. 


Table  5.2-15.  AUTOVON  Switch/PBX  Congestion  Report  File 


e 5.2-17.  ACOC  Level  Data  Base  Sizing 


5.3  SOFTWARE  CONSIDERATIONS  FOR  THE  ACOC 


A preliminary  software  design  for  the  ACOC  has  been  performed  jsing  the 
THREADS  design  methodology.  This  process  is  described  in  detail  in  Section  1.4. 

In  the  following  subsections  a detailed  software  design  for  the  ACOC  level  of  Unified 
Control  is  presented  in  terms  of  the  THREADS  (identified  during  the  design  effort) 
to  support  the  functional  capabilities  discussed  in  Section  5. 1. 

For  each  ACOC  function  a THREAD  flow  diagram  which  describes  the  processing 
steps  required  in  accomplishing  the  function  and  the  routines  supporting  each  process- 
ing step  is  presented.  A sizing  analysis  is  then  provided  which  addresses  individual 
routine  size  requirements  as  well  as  overall  ACOC  processing  system  size  require- 
ments including  estimates  of  lines  of  code  and  memory  occupancy.  Processor 
memory  requirements  are  then  addressed  including  support  software,  resident  data 
structures  and  overlay  techniques.  A parametric  processing  load  analysis  is 
provided  which  shows  processor  and  disk  load  requirements  for  the  ACOC  as  a 
function  of  various  system  event  occurrence  rates.  Finally,  the  general  character- 
istics of  processor  support  software  as  they  pertain  to  the  ACOC  level  of  unified 
control  are  discussed. 

5.3.1  ACOC  Software  Design 

The  following  paragraphs  present  a software  system  design  for  the  ACOC  in 
terms  of  54  ACOC  level  THREADS.  These  THREADS  are  derived  from  the  ACOC 
level  requirements  presented  in  Section  5. 1,  where  each  THREAD  supports  a 
specific  functional  requirement.  The  THREADS  are  first  presented  in  a hierarchical 
structure  which  shows  all  software  capabilities  available  to  each  functional  element  of 
unified  control  at  the  ACOC  level.  Each  THREAD  is  additionally  described  in  a 
THREAD  flow  diagram  which  shows  the  discrete  processing  requirements  and  individ- 
ual routines  necessary  to  accomplish  the  prescribed  functional.  Finally,  all  routines 
identified  in  the  THREAD  flow  diagrams  are  summarized  in  a hierarchical  computer 
program  structure  showing  the  various  levels  of  control  within  the  applications 
software  system. 


5. 3. 1. 1 ACOC  THREADS 


I i 
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Figure  5.3-1  summarizes  the  THREADS  which  comprise  the  ACOC  level  of 
unified  control.  The  figure  shows  a two-level  hierarchy  of  THREADS  supporting  each 
operational  element  serviced  by  the  ACOC  including  the  ACOC  Controller,  Sectors, 
other  ACOCs,  and  the  SATCOM  Controller. 


The  top  level  of  the  hierarchy  performs  I/O  and  preliminary  message  processing 
functions.  The  software  represented  by  these  THREADS  performs  line  handling, 
buffer  management,  and  task  scheduling  activities.  The  stimulus  to  these  THREADS 

is  generally  an  interrupt  or  other  condition  indicating  a call  for  input  or  output  ser- 

. 

vice,  while  the  response  is  a completed  I/O  operation  with  appropriate  subsequent 
processing  scheduled.  Each  subsequent  processing  task  is  supported  by  a distinct 
THREAD  located  on  the  second  level  of  the  hierarchy.  The  scheduling  activities 
performed  by  the  top  level  THREADS  serve  as  the  stimuli  to  the  various  second 
level  THREADS. 


The  second  level  THREADS  are  grouped  into  five  subtrees  corresponding  to  the 
five  sources  of  external  stimulus  to  the  ACOC.  These  groups  are  mapped  to  the  top 
level  THREAD  they  support  by  the  connectors  K through  O on  the  first  sheet  of  the 
figure.  To  examine  the  support  available  to  a given  ACOC  element  it  is  necessary 
only  to  inspect  the  corresponding  subtree  for  that  element. 


The  THREADS  contained  in  Figure  5.3-1  are  presented  in  an  abbreviated  for- 

1 

mat.  In  the  next  paragraph  each  THREAD  will  be  expanded  into  a flow  diagram  in 
order  to  show  the  detailed  processing  requirements  and  associated  software  require- 
ments  to  accomplish  the  function  supported  by  the  THREAD. 

5. 3. 1.2  THREAD  Flow  Diagrams 

Figures  5.3-3  through  5.3-8  show  the  detailed  flow  diagrams  for  the  ACOC  r 

level  THREADS.  Each  figure  contains  the  diagrams  for  all  THREADS  which  support 
a given  ACOC  element.  Table  5.3-1  summarizes  the  contents  of  these  figures. 
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The  basic  format  of  the  flow  diagram  is  shown  in  Figure  5.3-2.  The  stimulus 
and  response  information  will  be  the  same  as  indicated  in  the  abbreviated  formats 
used  in  the  THREAD  hierarchy.  However,  while  the  processing  information  is 
summarized  in  the  abbreviated  format,  it  is  expanded  into  3 series  of  more  precise 
steps  in  the  flow  diagram.  Each  step  also  lists  the  computer  programs  necessary 
to  support  the  indicated  processing. 

The  supervisory  level  and  I/O  diagrams  are  shown  in  Figure  5.3-3.  These 
THREADS  divide  into  two  basic  types.  The  first  five  THREADS  address  input  pro- 
cessing of  data  from  each  unified  control  element  which  communicates  directly  with 
the  ACOC.  In  adiition  to  input  handling  functions  they  perform  supervisory  schedul- 
ingfunctions  based  on  the  message  types  that  are  received.  The  remaining  three 
THREADS  perform  communications  output  handling  for  the  Sector,  ACOC,  and 
Journal  device  interfaces. 

Figure  5.3-4  shows  the  THREAD  diagrams  which  process  messages  received 
from  the  Sector.  The  majority  of  the  messages  received  from  the  Sector  are  of  three 
general  types:  responses  to  requests  for  data  from  the  Node  and  Sector  levels,' 
requests  to  supply  data  to  the  Node  and  Sector  levels,  and  fault  related  broadcast 
messages. 

Messages  are  also  passed  over  this  interface  containing  switch  equipment 
status  from  the  switched  networks.  Additionally,  AUTOVON  traffic  related  infor- 
mation is  forwarded  through  the  system  and  is  received  from  the  Sector.  Upon 
receipt  of  this  traffic  data,  the  network-wide  correlation  processing  function  is 
performed  to  determine  switch  related  problems.  This  correlation  process  is 
discussed  in  detail  in  Section  6 of  this  report. 

Figure  5.3-5  shows  the  ACOC  handling  software.  The  message  types  received 
from  other  ACOCs  are  similar  to  the  messages  received  from  the  Sectors.  Control 
directive  messages  arc  supported  in  both  directions  on  this  interface. 

The  ACOC  Controller  software  is  shown  in  Figure  5.3-6.  In  general,  most  of 
the  requests  made  from  this  position  are  for  retrieval  of  data  base  contents,  or  for 


issuing  control  directives  (reroute,  connectivity  modifications).  Both  transmission 
related  and  switched  network  related  status  information  is  available  in  the  local 
ACOC  data  base.  A detailed  description  of  traffic  display  data  for  AUTOVON  is 
contained  in  Section  6. 

Figure  5.3-7  shows  the  AUTODIN  STATS  THREAD  Diagrams.  This  software 
performs  thresholding  on  various  queue  lengths  reported  in  the  summary  message, 
and  performs  journaling  of  these  reports  for  reference  purposes. 

Figure  5.3-8  shows  the  SATCOM  Controller  THREAD  Diagrams.  The 
capabilities  available  to  this  position  include  fault  entry  and  closure  as  well  as 
various  system  status  requests.  The  SATCOM  Controller  position  is  operationally 
similar  to  a station  level  controller  position. 

In  the  next  paragraph,  all  of  the  computer  programs  which  are  identified  in 
Figures  5.3-3  through  5.3-8  are  presented  in  a computer  program  hierarchy  in 
order  to  show^the  relationships  of  the  various  routines  and  to  summarize  the 
applications  software  system  for  the  ACOC. 

5. 3. 1.3  Computer  Program  Hierarchy 

All  of  the  routines  which  are  identified  in  the  ACOC  level  THREADS  have  been 
structured  into  a six-level  program  hierarchy.  In  determining  the  appropriate 
level  for  a given  routine,  two  guidelines  are  followed.  First,  a given  routine  may 
call  only  these  routines  which  reside  at  lower  hierarchical  levels.  The  application 
of  this  rule  ensures  that  the  levels  of  the  hierarchy  indicate  the  various  levels  of 
control  within  the  software  system.  Second,  each  level  of  the  hierarchy  should 
be  functionally  homogeneous.  That  is,  routines  which  perform  similar  functions 
should  be  grouped  at  a given  hierarchical  level. 

Figure  5.3-9  shows  the  program  hierarchy  for  the  ACOC  level  of  unified 
control. 

The  top  level  of  the  hierarchy  contains  the  ACOC  SUPERVISOR  which  controls 
execution  of  all  scheduled  events  in  the  software  system. 
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The  second  level  contains  the  interrupt  driven  I/O  drivers  and  a series  of 
message  processors.  Each  message  processor  controls  the  support  activities  for 
one  of  the  major  input  sources  at  the  ACOC.  In  general,  these  routines  supervise 
message  decoding/validation  and  perform  overlay  retrieval. 

The  third  level  of  the  hierarchy  contains  the  routines  responsible  for  perform- 
ing major  operational  functions.  Such  functions  include  processing  individual 
ACOC  Controller,  SATCOM  Controller,  Sector,  and  ACOC  message  types. 

The  fourth  level  provides  significant  support  functions  to  the  various  third 
level  routines.  For  example,  the  third  level  ACOC  CONNECTIVITY  DISPLAY 
PROCESSOR  depends  heavily  on  the  four  connectivity  RETRIEVAL  routines  on  this 
level.  This  amount  of  functional  support  minimizes  duplication  of  software  between 
the  various  operational  function  routines  on  the  third  level.  In  addition,  it  pro- 
vides a level  of  insulation  between  the  functionally  oriented  routines  in  the  upper 
levels  and  the  various  data  base  structures  employed  in  the  lower  levels  of  the 
hierarchy. 

The  fifth  level  consists  largely  of  file  managers  for  the  various  components 
of  the  data  base.  These  file  managers  rely  heavily  on  the  sixth  level  generic  data 
base  management  support  routines  FIND,  GET,  CREATE,  DELETE  and  MODIFY 
for  access  to  the  various  files.  Additional  system  support  activities  supplied  on 
the  sixth  level  include  error  processing,  message  type  decoding  and  I/O  buffer 
management. 

5. 3. 2 Software  Sizing 

The  following  two  paragraphs  present  a software  sizing  analysis  for  the 
ACOC.  In  the  first  paragraph,  each  routine  identified  during  the  design  effort  is 
addressed  in  terms  of  estimated  lines  of  code  and  program  and  data  occupancy  require- 
ments. The  second  paragraph  then  presents  ACOC  processor  memory  requirements 
based  on  a two-level  overlay  structure. 
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5. 3c  2.1  Program  Sizing 

The  sizing  of  the  programs  presented  in  this  paragraph  is  base  don  an  estima- 
tion of  the  number  of  lines  of  HOL  code  required  to  implement  each  routine  in  the 
ACOC  program  hierarchy  (Paragraph  5.3. 1.3),  plus  additional  memory  required 
to  accommodate  data  for  each  routine.  This  sizing  includes  applications  software  and 
operating  system  enhancements  only  and  assumes  that  the  host  computer  supplies 
support  software  capabilities  as  described  in  5.3.4. 

Table  5.3-2  summarizes  the  program  sizing  for  the  Sector.  The  program 
occupancy  for  each  routine  is  based  on  an  expansion  factor  of  15  bytes  of  storage  for 
each  line  of  HOL.  This  ratio  is  typical  of  16-bit  word  length  machines  using  currently 
available  HOL  compilers.  Further  justification  of  this  expansion  ratio  is  provided  in 
Section  1.4.  Where  applicable,  the  data  occupancy  for  each  routine  includes  buffer 
and  table  space  requirements.  Without  the  use  of  overlays,  the  total  memory  require- 
ment for  theACOC  applications  software  is  223K  bytes. 

5. 3. 2. 2 Processor  Memory  Requirements 

The  software  system  described  in  Section  5.  3.1  is  functionally  partitionable 
and  is  susceptible  to  incorporation  into  an  overlay  structure.  The  use  of  overlays, 
where  on-line  secondary  storage  capabilities  are  available,  minimizes  processor 
memory  requirements  by  retaining  low  demand  software  in  secondary  storage. 

An  overlay  structure  for  the  ACOC  software  was  developed  by  dividing  the 
routines  contained  in  the  ACOC  program  hierarchy  into  three  categories:  resident, 
element  support  and  functional  support. 

The  resident  routines  are  high  demand  routines  which  support  supervisor/ 
control  of  all  processing  functions.  Such  routines  as  the  ACOC  SUPERVISOR,  and 
the  I/O  drivers  are  considered  in  this  category  since  they  are  used  to  support  high 
demand  system  functions.  Table  5.3-3  summarizes  the  resident  routines  for  the 
ACOC.  These  routines  require  15,785  bytes  of  memory. 
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The  routines  which  compose  the  support  overlays  are  also  summarized  in 
Table  5.3-3  according  to  the  operational  element  which  they  support.  The  elements 
and  their  respective  support  sizes  are  summarized  below: 

ACOC  Controller  Support  71,925  bytes 

Sector  Support  71,625  bytes 

ACOC  Support  67,500  bytes 

DIN  STATS  9, 375  bytes 

SATCOM  96, 300  bytes 

The  routines  which  are  used  for  supporting  an  operational  element  are  defined 
to  be  those  routines  that  would  be  needed  by  any  of  the  functional  routines  supporting 
the  given  element. 

The  routines  comprising  the  functional  overlays  for  the  ACOC  Controller, 
Sector,  ACOC,  DIN  STATS,  and  SATCOM  are  summarized  in  Table  5.3-4.  Depend- 
ing on  the  function  to  be  performed,  only  one  of  these  overlays  would  be  in  memory 
at  any  time. 

In  order  to  determine  the  amount  of  memory  required  at  the  ACOC  for  appli- 
cations software,  it  is  necessary  to  add  the  memory  requirements  for  the  resident 
routines,  support  overlay  routines  and  the  largest  functional  overlay  module  for 
each  ACOC  element.  Table  5.3-5  shows  that  the  largest  memory  requirement 
occurs  for  processing  Sector  input.  In  this  case  the  applications  software  requires 
114,410  bytes  of  main  memory. 

In  addition  to  the  applications  software  requirements,  the  processor  memory 
must  accommodate  the  resident  portion  of  a disk-based  operating  system.  Based 
upon  currently  available  real-time  operating  system  software,  a residency  require- 
ment for  an  operating  system  providing  the  support  outlined  in  Section  5.3.4  is 
12,000  bytes.  This  does  not  include  occupancy  within  the  operating  system  for  the 
I/O  drivers  and  buffer  areas  which  were  sized  as  part  of  the  applications  software. 
The  total  ACOC  memory  requirement  is  now  determined  to  be  126K  bytes. 
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5.3.3  ACOC  Processing  Load 
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A worst  case  sustained  load  analysis  for  the  ACOC  is  presented  in  this  para- 
graph. Both  processor  and  disk  utilizations  are  considered  because  of  the  largo 
amount  of  dat . base  access  activity  required  to  support  unified  control  functions. 

The  utilizations  are  parametrically  derived  and  presented  in  a series  of  curves 
which  show  utilization  as  a function  of  the  rate  of  Sector  and  ACOC  fault  notification, 
SATCOM  fault  entry,  and  DIN  STATS  Summary  Message  receipt. 

Table  5.3-6  summarizes  the  set  of  worst  case  algorithms  on  which  the  ACOC 
load  analysis  is  based.  Each  algorithm  is  analyzed  for  the  number  of  assembly 
language  instructions  executed  and  the  number  of  disk  accesses  performed  for  single 
execution  of  the  algorithm.  The  flowcharts  and  detailed  analysis  of  these  algoruthms 
are  contained  in  Appendix  A to  this  report. 

Algorithms  A1  and  A2  perform  fault  notification  broadcast  processing  for 
messages  received  from  the  Sectors  and  other  ACOCs  respectively.  Algorithm  A3 
performs  input  processing  and  thresholding  of  AUTODIN  STATS  switch  summary 
messages.  Algorithm  A4  accepts  fault  reports  initiated  by  the  SATCOM  Controller. 
Algorithm  A5  is  the  worst  case  display  request  that  can  be  made  from  theACOC 
Controller  position.  This  algorithm  will  be  used  later  in  this  paragraph  to  establish 
average  and  worst  case  operator  response  times. 

Table  5.3-7  shows  the  derivation  of  the  worst  case  I/O  support  load.  For  each 
element  interfaced  at  the  ACOC  the  maximum  aggregate  bandwidth  is  computed  in 
terms  of  the  number  of  assembly  level  instructions  required  per  second  to  effect  the 
I/O  transfers.  For  the  worst  case  it  is  assumed  that  data  will  be  passed  a character 
at  a time  on  the  processor  I/O  bus.  From  this  table  the  I/O  load  at  the  ACOC  is  16,290 
instructions/sec. 

Figure  5.3-10  presents  the  derivation  of  the  processing  load  at  the  ACOC. 

From  Equation  (1)  it  is  seen  that  the  total  processing  load  is  t',e  sum  of  the 
loads  supporting  Sector  (PgECTOR).  and  ACOC  (PACOC)  fault  notifications,  STATS 
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summary  message  processing  (PgTATS).  SATCOM  Controller  fault  entry  processing 
(PgATcoM*’  Cycle  stealinS  due  to  disk  DMA  operation  (PDISK>.  and  communications 
I/O  (P  ).  Equation  (2)  shows  that  the  Sector,  ACOC,  STATS,  and  SATCOM 
processing  loads  are  the  products  of  a single  occurrence  loads  and  event  occurrence 
rates.  Equations  (3)  through  (6)  show  that  the  computation  of  the  single  occurrence 
loads  for  the  Sector,  ACOC,  STATS,  and  SATCOM  Controller  respectively.  Since 
the  sustained  load  will  be  computed  for  a one  minute  interval,  a time  conversion 
factor  is  included  in  these  equations  to  find  the  average  second  load.  Equation  (7) 
accounts  for  memory  cycle  stealing  due  to  the  disk  DMA  activity.  An  average  disk 
access  size  of  one  25G  work  block  is  assumed.  Equation  (8)  shows  the  communica- 
tions I/O  load.  The  worst  case  I/O  lor  as  presented  in  Table  5.3-7  is  assumed. 

By  rewriting  Equation  (2),  Equation  (9)  now  shows  the  ACOC  processing  load  as  a 
function  of  the  rate  of  message  receipt  from  the  other  system  elements.  This 
equation  is  plotted  in  Figure  5.3-11  for  values  of  Roc,orr<~.D  from  0 to  300,  and 
Racoc  *rom  0 to  20*  °n  first  sheet  of  the  figure  the  SATCOM  Controller  and 
STATS  interfaces  are  assumed  to  be  idle.  On  the  second  sheet,  the  load  including 
the  worst  case  demands  from  these  elements  is  plotted.  Because  of  the  low  band- 
width of  sustained  activity  the  average  load  over  the  worst  case  minute  is  small. 

Figure  5.3-12  shows  the  derivation  of  the  disk  load  at  the  ACOC.  Equation  (1) 
shows  that  the  total  disk  load  is  the  sum  of  the  disk  loads  supporting  the  various 
ACOC  elements.  These  quantities  are  a function  of  the  rate  of  fault  related  event 
occurrence  as  shown  in  Equation  (2).  Equation  (7)  shows  the  total  disk  load  as  a 
function  of  these  occurrence  rates.  Figure  5.3-13  plots  D as  a function  of  the 

A 

same  variables  and  ranges  used  in  Figure  5.3-11  for  P . The  100  percent  utilization 

A 

line  for  a typical  moving  head  disk  with  sufficient  capacity  to  accommodate  the  ACOC 
data  base  is  also  indicated  on  this  figure.  The  utilization  threshold  is  based  on  a 50 
millisecond  average  access  time. 

Extending  the  worst  case  example  described  in  Paragraph  4.3.3  the  rate  of 

fault  notification  message  receipt  from  the  Sector  (RCDrTriD)  becomes  225  faults/min 

SECTOR 
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(5  Sectors  @ 45  messages/Sector).  Assuming  that  three  DIN  STATS  messages  arrive 
during  this  period,  slightly  more  than  10  notification  messages  can  be  processed  from 
other  ACOCs  before  disk  saturation  occurs.  The  functional  processing  load  for  this 
saturating  condition  is  seen  from  Figure  5.3-11  to  be  about  26,000  instructions/sec. 
This  constitutes  a small  average  second  load  during  the  worst  case  minute. 

The  worst  case  is  an  extreme  example  since  the  average  fault  occurrence  rate 
is  projected  to  be  only  about  2,000  faults./day  assuming  the  presence  of  automated 
monitoring  equipment. 

Algorithm  A5  can  be  used  to  determine  operator  response  times  as  a functionof 
the  relative  load  on  the  ACOC  processor  and  disk.  The  algorithm  requires  that 
18,012  instructions  and  16  disk  accesses  be  performed.  The  response  time  will  be 
dominated  by  disk  access  time.  The  disk  activity,  assuming  no  contention  for  disk 
resources  would  require  800  milliseconds  (16  accesses  @ 50  milliseconds/access). 

Assuming  a relatively  slow  processing  capability  (8  microsecond  average 
instruction  time)  the  processing  would  require  144  milliseconds  (no  contention). 

The  total  time  until  the  connectivity  request  processing  is  completed  and  the 
data  is  ready  for  display  is  then  .944  seconds  when  no  other  activity  is  ongoing. 

Assuming  that  the  ACOC  is  processing  225  Sector  level,  10  ACOC  level  fault 
notifications,  and  the  worst  case  SATCOM  and  STATS  messages  the  response  time  for 
this  request  then  degrades  to  2.10  seconds  (1.75  seconds  total  for  disk,  .352  seconds 
for  processing). 

5.3.4  Support  Software 

The  operational  and  development  software  capabilities  required  to  support 
ACOC  processing  functions  are  similar  to  the  capabilities  described  for  the  Node 
and  Sector.  This  similarity  is  due  to  the  high  degree  of  functional  commonality 
between  all  levels  of  unified  control.  For  a description  of  the  support  software 
requirements  see  Section  3.3.4. 
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Figure  5.3-1.  ACOC  Threads  (Sheet  1 of  6) 


Figure  5.3-1.  ACOC  Threads  (Sheet  3 of  6) 
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Figure  5.3-1.  ACOC  Threads  (Sheet  5 of  6) 


Figure  5.3-1.  ACOC  Threads  (Sheet  6 of  6) 
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Figure  5.3-2.  Format  of  a THREAD  Flow  Diagram 


Figure  5.3-4.  Sector  — ► ACOC  THREAD  Diagrams  (Sheet  2 of  5) 


Figure  5.3-4.  Sector ►AC OC  THREAD  Diagrams  (Sheet  4 of  5) 


Figure  5.3-5.  ACOC  ► ACOC  THREAD  Diagrams  (Sheet  1 of  4) 


ACOC ►ACOC 


Figure  5.3-5.  ACOC  ► ACOC  THREAD  Diagrams  (Sheet  3 of  4) 


Figure  5.3-6.  ACOC  Controller  ACOC  THREAD  Diagrams  (Sheet  1 of  5) 


Figure  5.3-6.  ACOC  Controller  ► ACOC  THREAD  Diagrams  (Sheet  3 of  5) 


Figure  5.3-6.  ACOC  Controller  ACOC  THREAD  Diagrams  (Sheet  5 of  5) 


Figure  5.3-8.  SATCOM  Controller ► ACOC  THREAD  Diagrams  (Sheet  1 of  2) 
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Figure  5. 3-9.  Computer  Programs  Hierarchy 
for  the  ACOC 
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ACOC  Processing  Load: 


P=P  +P  +P  4-  P + P +P 

A SECTOR  ACOC  STATS  SATCOM  DISK  I/O 

PA  = lsector  rsector  + lacoc  racoc  + lstats  rstats  + 


(1) 

(2) 


where 


lsatcom  rsatcom  pdisk  + pi/o 


L = Load  due  to  X 
A 

R = Rate  of  occurrence  of  X 

A 


"SECTOR  ; ^SECTOR 

= <I 

' Al'  lSEC  ’ 

= (1005)  (1/60) 
= 16.75 

= (I  ) (SSL, 

ACOC  ' A2;  'SEC 
= (2475)  (1/60) 

= 41.25 

MIN 

"STATS  ~ (IA3)  (SEC  ) 

= (2500)  (1/60) 

= 41.67 

-a 

"SATCOM  ' A4'  'SEC  ’ 
= (5445)  (1/60) 
= 90.75 


) (Time  conversion) 


(3) 


(4) 


(5) 


(6) 


DISK 


= 256  D , 


(7) 


Figure  5.3-10.  Derivation  of  the  ACOC  Processing  Load 
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where 


I 

I 


1 


ACOC  Disk  Load: 

DA  °SECTOJR  + °ACOC  + dstats  + dsatcom 

°A  ' ASECTOR  ^SECTOR  + AACOC  RACOC  + A STATS  RSTATS  + 

asatcom  rsatcom 

where 


A^  = Number  of  accesses  due  to  X 


Rj,  = Rate  of  occurrence  of  X 
A, 


,A  min 

‘SECTOR  ( Al'  (SEC’ 


ACOC 


= (4)  (1/60) 

= .07 

. MIN 
(AA2*  (SEC  ’ 

= (16) (1/60) 

= .27 

A = (A  ) (MIN) 

STATS  A3  SEC' 

= (3) (1/60) 

= .05 


SATCOM 


. . 4 MIN 

AA4  (SEC 

= (26)  (1/60) 

= .43 


so 


Da  = .07  R 


SECTOR 


+ . 27R 


ACOC 


. 05R„_.^  + 
STATS 


.43R 


SATCOM 


Figure  5.3-12.  Derivation  of  the  ACOC  Disk  Load 
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Table  5.3-1.  Guide  to  ACOC  Level  THREAD  Diagrams 


Element 

Figure  Containing  Detailed 
Flow  Diagrams 

Supervisor  and  I/O  Level 

5.3-3 

Sector 

5.3-4 

ACOC 

5.3-5 

ACOC  Controller 

5.3-6 

AUTODIN  (STATS) 

5.3-7 

SATCOM  Controller 

5.3-8 

Table  5.3-2.  ACOC  Sizing  Summary  (Sheet  2 of  4) 
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Table  5.3-2.  ACOC  Sizing  Summary  (Sheet  4 of  4) 
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Table  5. 3-4.  ACOC  Functional  Overlay  Sizing  Summary  (Sheet  6 of  6) 
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Table  5.3-5.  Determination  of  the  Largest  Memory  Requirement 

for  the  ACOC 


Element 

Resident 

Routines 

Support 

Overlay 

Largest 

Functional 

Overlay 

Total 

Occupancy 

ACOC 

Controller 

15,785 

71,925 

11,250 

98,960 

Sector 

15,785 

71,625 

27,000 

114,410 

ACOC 

15,785 

67,500 

27,000 

110,285 

DIN  STATS 

15,785 

9,375 

- 

25,160 

SATCOM 

15,785 

96,300 

- 

112,085 

R 


Table  5.3-6.  Summary  of  Algorithms  for  the  ACOC 


Algorithm Function 

A1  Process  Fault  Notification  Broadcasts 

from  Sectors 

Process  Fault  Notifications  from 
ACOCs 

Process  a Switch  Summary  Message 
from  STATS 

Request  to  Enter  a Fault  Report 
(SATCOM) 


# ASM 
Inst 


# Disk 
Accesses 


1 

l 


Table  5.  3-7.  ACOC  I/O  Load 


SOURCE 

NO. 

LINES 

LINE 

RATE 

(bps) 

NO.  BYTE 

TRANSFERS 

(B/Sec/Line) 

AGGREGATE 

TRANSFERS/ 

SEC 

LOAD 

TRANSFER 

(Inst) 

AGGREGATE 

LOAD 

ACOC 

to 

2400 

300 

1200—^ 

3 

3600 

SECTOR 

5 — 

2400 

300 

3000- 

3 

9000 

STATS 

3 

75 

10 

30 

3 

90 

ACOC  Cont 

3 

2400 

300 

900 

3 

2700 

SATCOM 

1 

2400 

300 

300 

3 

900 

TOTAL  I/O  LOAD  - 16,290  Inst/Sec 


Full  Duplex 


5.4  HARDWARE  CONSIDERATIONS  FOR  THE  ACOC 
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In  the  following  subsections  the  hardware  considerations  for  the  ACOC  level  of 
unified  control  including  processor,  peripheral  equipment,  and  processor  interface 
characteristics  are  addressed. 

5.4.1  ACOC  Processor 

The  ACOC  processing  system  as  described  in  Section  5.3  primarily  performs 
data  base  management  and  display  processing  functions.  A basic  characteristic  of 
such  functions  is  that  they  are  highly  I/O  bound  by  disk  and  terminal  access  require- 
ments as  demonstrated  by  the  ACOC  load  analysis  presented  in  Paragraph  5.3.3. 
Assuming  the  ACOC  software  to  be  implemented  in  a multi-programmed  environment, 
a task  switching  overhead  may  be  applied  in  a manner  similar  to  that  presented  in 
Paragraph  3.4. 1 for  the  Node.  Using  an  estimate  of  1 millisecond/switch  the  ACOC 
task  overhead  is  determined  to  be  239  milliseconds  (239  messages  @ 1 millisecond/ 
switch).  The  sustained  ACOC  load  is  presented  for  three  classes  of  16-bit  word 
length  minicomputers  below: 

8 microsecond  average  instruction  time  - 0.212 

5 microsecond  average  instruction  time  - 0. 134 

2.5  microsecond  average  instruction  time  - 0.069 

The  relatively  low  bandwidth  of  processing  requirements  at  the  ACOC  is  apparent 
from  this  data.  At  these  bandwidths  processor  speed  is  not  a critical  factor  in 
performing  real  time  functions.  Background  functions,  including  operator  interaction, 
are  by  their  nature  very  low  bandwidth  and  constitute  a distributable  load  which  would 
not  degrade  real  time  functions. 

The  processor  memory  requirement  for  the  ACOC  is  estimated  to  be  126K  bytes 
(Paragraph  5.3.2).  The  ACOC  processor  should  at  a minimum  support  a memory 
configuration  adequate  to  satisfy  this  requirement  and  should  provide  for  future  memory 
growth  of  100  percent  to  allow  for  functional  expansion  of  ACOC  capabilities. 

The  general  hardware  and  support  software  considerations  discussed  in 
Paragraph  3.4.1  for  the  Node  apply  to  the  ACOC  level  of  unified  control  as  well,  due 
to  the  functional  similarities  between  all  elements  of  unified  control. 
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5.4.2  ACOC  Peripherals  and  Interfaces 

Figure  5.4-1  shows  the  hardware  configuration  for  the  ACOC  which  includes  a 
processor  configured  with  a minimum  of  128K  bytes  of  main  memory,  10M  bytes  of 
random  access  disk  storage  for  data  base  and  program  overlay  storage,  a magnetic 
tape  unit  for  long  term  journal  retention,  and  as  many  as  three  KB/CRT  terminals  with 
local  hard  copy  capabilities  to  support  ACOC  Controller  positions  and  provide  status 
monitor  capability.  Communications  between  the  ACOC  and  the  Sectors  are  provided 
by  a total  of  five  2400  bps  serial  synchronous  data  channels.  Two  similar  channels 
provide  inter-ACOC  communications. 

The  data  base  storage  requirement  at  the  ACOC  is  estimated  to  be  6. 7M  bytes 
(Section  5.2).  In  order  to  provide  adequate  space  for  applications  and  support  soft- 
ware a disk  capacity  no  less  than  10M  bytes  should  be  supplied.  Because  of  the  high 
disk  utilization  at  the  ACOC,  the  average  access  time  for  the  device  should  be  less 
than  50  milliseconds. 

The  magnetic  tape  unit  should  be  compatible  with  the  Node  and  Sector  tape  units 
to  minimize  logistic  and  maintenance  related  costs.  Further,  the  compatability  would 
allow  batch  reduction  of  journal  data  to  be  accomplished  in  a single  facility  for  the 
entire  system. 

The  highly  interactive  nature  of  ACOC  Controller  activity  requires  that  a 
powerful  KB/CRT  terminal  be  used  to  support  this  position.  The  required  capabilities 
of  this  terminal  are  the  same  as  those  described  for  the  Node  terminals  (Paragraph 
3.4.2). 

In  order  to  provide  compatability  among  all  internal  unified  control  communi- 
cations interfaces,  the  synchronous  channels  for  the  ACOC  should  have  the  same 
capabilities  as  the  channels  described  for  use  at  the  Node  (Paragraph  3.4.2). 
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Figure  5.4-1.  ACOC  Hardware  Configuration 


SECTION  6 - AUTOVON  REQUIREMENTS 


6.1  GENERAL 

This  section  treats  the  requirement  to  provide  switch  and  network  operational 
efficiency  and  traffic  flow  data  to  the  ACOC  Network  Controller  and  the  associated 
Switch  Controller.  This  individual  switch  and  network  visibility  is  required  if  the 
Network  Controller  is  to  make  decisions  and  implement  controls  within  the  switched 
network.  The  data  reduction  and  transmission  will  provide  displays  of  traffic 
indicators,  call  processing  efficiency,  equipment  status  and  suggested  actions  to 
alleviate  congested  traffic  conditions  caused  by  overload  or  equipment  failure. 

Processing  of  data  at  station  level  and  ACOC  level  are  considered.  For  each 
level,  the  sources  of  data,  data  requirements,  equipment  interface,  processor 
memory  storage  requirements,  desired  data  outputs,  and  the  algorithms  necessary 
for  output  development  are  considered. 

The  base  line  assumptions  made  in  the  Unified  Network/Traffic  Transmission 
Media  Control  Interim  Report,  Paragraph  3.3.2.5b,  that  the  proposed  AUTOVON 
diagnostic  processor  will  be  installed  and  operational  and  capable  of  receiving  other 
AUTOVON  related  data  is  continued  in  this  report. 

6.  2 AUTOVON  SWITCH  STATION  LEVEL  MODULES 

The  AUTOVON  Switch  Station  Level  Module  is  defined  as  "the  processing 
module  necessary  to  reduce  raw  or  partially  processed  inputs  from  AUTOVON  switch 
equipment  to  a form  which  can  be  forwarded  to  the  Node  or  ACOC  for  display  or 
further  processing". 

6.2.1  Input  Sources 

The  following  paragraphs  contain  considerations  and  selection  of  preferred  data 
sources. 
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6.2. 1.1  Source  Considerations 


Data  acquisition  from  the  following  listed  sources  has  been  considered: 

a.  TDCS  - Output  from  Traffic  Data  Collection  System  (TDCS)  were 
considered  as  sources  for  traffic  conditions,  line  and  trunk  status,  and 
equipment  status. 

b.  ACAS  - The  output  from  AUTOVON  Centralized  Alarm  System  (ACAS)  was 
considered  as  a source  for  equipment  status  and  traffic  overload  conditions. 

c.  Diagnostic  Processor  - The  Diagnostic  Processor  was  considered  as  a 
source  for  equipment  failure  data  and  certain  traffic  overload  indications. 

d.  TDCS  Interface  Buffer  (IB)  and  Status  Monitor  Interface  (SMI)  - The 
AUTOVON  switch  interface  circuits  provided  for  TDCS  and  ACAS  were 
considered  as  sources  of  call  processing  data,  traffic  overload  conditions 
and  equipment  status  indications. 

e.  Lines  and  Trunks  - The  line  and  trunk  circuits  were  considered  as  sources 
for  line  and  trunk  status. 

f.  AUTOVON  Trunk  Scanner  Read  Buffer  - The  Read  Buffer  circuit  of  the 
AUTOVON  Switch  Trunk  Scanner  Section  was  considered  as  a source  for 
line  and  trunk  status. 


6.  2. 1.  2 Source  Selection 


Selection  of  recommended  input  sources  was  made  on  the  basis  of  factors 
presented  in  the  following  subparagraphs. 

6.  2. 1.2.1  TDCS  Outputs 

a.  An  output  from  an  additional  TDCS  data  port  was  considered  for  all  data 
except  equipment  failure  indication.  This  output  was  not  considered  to  be 
feasible  because  of  the  TDCS  Processor's  lack  of  an  operating  system, 
overlay,  high  level  language  support,  and  the  absolute  assembly  of  the 
current  TDCS  software. 
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Access  to  TDCS  data  would  require  modification  of  the  TDCS  software 
principally  involved  with  the  Executive  Control  Program  and  the  interrupt 
handling  routines.  The  modifications  to  the  interrupt  handling  routines 
involve  incorporating  the  additional  software  drivers  necessary  to  support 
continual  access  by  the  AUTOVON  Switch  Station  level  module.  Additional 
software,  normally  supplied  by  a fully  supported  operating  system,  would 
need  to  be  developed.  This  software  would  have  to  be  resident  in  the  unpaged 
region  of  the  main  memory  of  the  TDCS  processor.  A major  impact  of 
this  approach  would  be  the  necessity  of  developing  all  of  the  required 
additional  TDCS  software  in  assembly  language,  since  a high  order 
language  (HOL)  is  not  available. 

b.  The  extraction  of  line,  trunk,  and  equipment  status  from  the  CCL  multi- 
plexer output  of  TDCS  was  considered.  This  data  source  was  considered 
impractical  because  TDCS  must  be  in  Traffic  Data  Collection  Mode  or  Call 
Data  Collection  Mode  for  the  CCL  multiplexer  output  to  be  active.  While 
one  of  the  modes  is  frequently  in  use,  the  AUTOVON  Switch  Station  level 
module  will  require  continuous  access  to  the  status  of  all  lines  and  trunks 
as  seen  by  the  AUTOVON  switch  common  control. 

6.2. 1.2.2  A CAS  Output 

The  serial  output  of  ACAS  was  considered  as  a source  for  equipment  status  and 
traffic  overload  condition.  The  limited  data  available  from  this  source  did  not  appear 
to  justify  the  use  of  a separate  slow  operating  (75  baud)  serial  input. 

6.  2. 1.  2. 3 Diagnostic  Processor 

The  diagnostic  processor  as  proposed  in  the  Computer  Sciences  Corporation 
Special  Study  on  Development  of  an  Enhanced  and  Expanded  490L  AUTOVON  Switch 
Trouble  Diagnostic  Capability,  dated  February  1977,  appears  to  be  the  most 
desirable  source  for  equipment  failure  data.  Correlation  of  certain  traffic  overload 
conditions  using  diagnostic  processor  data  also  appears  feasible. 
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6.  2. 1.  2.4  TDCS  Interface  Buffer  (IB)  and  Status  Monitor  Interface  (SMI) 

a.  Call  Processing  Data  - The  most  logical  source  of  call  processing  data  is 
the  AUTOVON  Switch  Register  Memory.  The  continuously  changing  call 
processing  data  used  by  the  AUTOVON  switch  in  processing  calls  is  now 
presented  to  TDCS  from  the  IB  circuit,  and  the  equipment  status  used  in 
TDCS  and  ACAS  is  presented  for  interface  in  the  SMI  circuit. 

The  timing  developed  for  Register  word  transmittal  to  TDCS  can  be  used 
for  interfacing  to  an  input  port  of  the  processor  containing  the  AUTOVON 
Switch  Station  Level  Module.  The  outputs  of  the  Register  Word  flip  flops 
at  the  IDF  could  be  paralleled  using  high  impedance  gating,  or  a more 
discrete  interface  could  be  developed  by  taking  the  0 side  outputs  of  the  IB 
circuit  flip  flops  for  use  in  the  AUTOVON  Switch  Station  Level  Module. 

b.  Equipment  Status  Leads  - Those  leads  now  interfaced  to  TDCS  via  CCL 
logic,  but  not  continuously  available  from  TDCS  are  available  primarily  in 
the  SMI  circuit.  An  interface  for  this  data  can  be  easily  adapted  to  a 
standard  processor  input  port. 

6.2. 1.2. 5 Lines  and  Trunks 

The  status  of  lines  and  trunk  circuits  required  for  maintenance  of  call  registers 
is  available  at  the  individual  line  and  trunk  circuits  and  would  require  a multiple 
scheme  as  elaborate  as  the  TDCS  CCL  interface.  The  extensive  additional  hardware 
required  for  this  scheme  does  not  justify  acquiring  the  line  and  trunk  status. 

6. 2. 1.  2. 6 AUTOVON  Switch  Trunk  Scanner  Read  Buffer 

Line  and  trunk  status  as  seen  by  the  AUTOVON  switch  is  available  every  two 
seconds  at  the  Trunk  Scanner  Read  Buffer.  This  status  includes  all  marked 
precedences,  maintenance  busy,  and  originating  busy.  The  interface  required  to 
make  these  outputs  available  to  a processor  input  port  would  consist  of  flip  flop 
buffers,  and  a word  available  signal  similar  to  that  now  provided  for  Register 
Memory  in  the  Interface  Buffer  circuit. 
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6.2.2  Input  Data 

The  majority  of  the  AUTOVON  switch  data  currently  being  utilized  by  TDCS 
will  be  useful  in  developing  the  flag,  displays  and  decisions  for  relief  of  traffic 
congestion  required  by  the  network  and  switch  controllers  for  effective  supervision 
of  the  AUTOVON  network. 

6.  2.  2. 1 Data  Currently  Available  at  Interface  Points 

The  data  currently  available  falls  into  two  broad  categories.  They  are  call 
processing  data  and  equipment  status  data. 

6.  2.  2. 1. 1 Call  Processing  Data 

The  call  processing  data  is  that  available  through  the  interface  buffer  from  the 
AUTOVON  switch  Register  Memory.  This  data  is  that  necessary  for  the  measurement 
of  all  parameters  surrounding  the  switch's  handling  of  each  call.  From  it,  the 
efficiency  of  each  switch's  operation  can  be  developed.  Figure  6.  2-1  slows  the 
layout  of  this  data  as  it  is  used  in  the  switch  and  Figure  6.  2-2  shows  the  layout  and 
movement  of  these  words  by  the  AUTOVON  switch  and  its  proposed  use  by  the 
AUTOVON  Switch  Station  level  module. 

6.2.2. 1.2  Equipment  status  now  available  at  interface  points  includes  a maximum 
of  1134  leads  as  follows; 

• Out  of  Service  Conditions  for  Logics,  Memories,  and  Switch  and  DSA 
Markers  (9  Leads) 

• System  Stop  Clock  and  Comparator  Manual  Mode  (2  Leads) 

• Line  Load  Control  Status  (Manual  Class-of-Service)  (3  Leads) 

• Maintenance  Busy  Conditions  for  Register  Junctors  (24  Leads) 

• Maintenance  Busy  Conditions  for  TCMF  Receivers  (15  Leads) 

• Maintenance  Busy  Conditions  for  MF  2/6  Transceivers  (15  Leads) 

• Service  Busy  Conditions  for  TCMF  Receivers  (15  Leads) 
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Figure  6.2-2.  Layout  and  Movement  of  AUTOVON  Call 
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• Service  Busy  Receive  Mode  Conditions  for  MF  Transceivers  (15  Leads) 

• Service  Busy  Transmit  Mode  Conditions  for  MF  Transceivers  (15  Leads) 

• Service  Busy  Tandem  Mode  Conditions  for  MF  Transceivers  (15  Leads) 

• Service  Busy  Conditions  for  Register  Junctors  (24  Leads) 

• Service  Busy  Dial  Pulse  Transmit  for  Register  Junctors  (24  Leads) 

• Service  Busy  Dial  Pulse  Receive  for  Register  Junctors  (24  Leads) 

• Automatic  Traffic  Overload  Protection  (ATOP)  (lLead) 

• All  Register  Junctors  Busy  (TARB)  (1  Lead) 

• All  Receivers  (2/8)  Busy  (TATTB)  (1  Lead) 

• All  Transceivers  (2/6)  Busy  (TAMFB)  (1  Lead) 

• Group  Busy  Leads  (30  Leads) 

• Line  and  Trunk  Busy  Status  (Maximum  900) 

These  leads  are  presently  multiplexed  to  the  TDCS  Processor  by  the  TDCS  CCL 
circuitry.  However,  the  inaccessibility  of  the  bulk  of  the  data  via  the  multiplexer  of 
the  TDCS  CCL  circuitry  will  require  either  a duplication  of  that  circuitry  or  an 
alternate  method  of  acquiring  the  status. 

The  line  and  trunk  busy  status  can  be  acquired  via  the  Trunk  Scanner  memory  if 
additional  buffering  in  the  Interface  Buffer  is  provided.  This  is  a simple  alternative 
to  duplicating  CCL.  There  is  a bonus  here  in  that  the  status  as  seen  by  the  switch 
translator  including  all  precedences  is  available. 

There  are  two  possible  methods  of  acquiring  the  234  equipment  status  leads 
data  without  duplicating  the  CCL.  These  are: 

a.  The  trunk  scanner  uses  only  every  second  memory  cycle,  therefore,  the 
intervening  cycle  could  be  used  to  multiplex  the  equipment  status  data  via 
the  same  input  port  as  the  register  junctor  data  and  the  trunk  scanner  line 
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and  trunk  status.  This  would  require  multiplexing  an  additional  eight  sets 
of  data  at  two  processor  words  per  set,  or  a complete  scan  of  all  equip- 
ment status  every  2.56  milliseconds.  Figure  6.2-3  is  a chart  of  AUTOVON 
switch  timing  showing  the  timing  relationship  between  data  now  provided  to 
TDCS  and  additional  data  from  trunk  scanner  memory. 

b.  All  except  68  of  the  234  status  leads  can  be  developed  from  data  contained 
in  register  memory  and  trunk  scanner  busy  idle  status.  A simpler  multi- 
plex scheme  would  result  from  using  this  method  at  the  cost  of  a more 
involved  program  in  the  AUTOVON  processor  module.  The  68  required 
leads  could  be  multiplexed  during  alternate  trunk  scanner  memory  cycles 
as  three  sets  of  data.  The  time  required  to  scan  the  68  equipment  status 
items  once  would  be  960  microseconds.  The  remaining  166  items  could 
be  developed  on  an  as  required  basis  by  the  AUTOVON  processor  module, 
or  could  be  cyclically  developed  and  stored  regularly  by  the  program. 

Either  of  the  approaches  outlined  in  a and  b will  provide  a large  equipment 
cost  saving  because  the  TDCS  CCL  would  not  have  to  be  duplicated.  The  reduction 
in  sample  leads  to  a manageable  number  also  reduces  the  potential  for  failure  of 
interface  components. 

The  timing  requirements  can  be  reduced  to  the  input  from  AUTOVON  of  seven 
processor  words  every  160  microseconds.  This  is  within  the  I/O  capability  of  one 
I/O  port  of  most  miniprocessors  currently  available. 

6.  2.  3 Interface  Design  Requirements 

The  interface  design  requirements  consists  of  two  separate  phases,  data 
currently  available  and  data  that  can  be  obtained  by  expansion  of  the  Traffic  Data 
Collection  System  (TDCS)  Interface  Buffer  IB  circuit. 


6. 2. 3. 1 Current  Data  Interface 


The  current  data  available  consists  of  AUTOVON  switch  register  memory 
(scratch  pad)  contents  during  call  processing  and  AUTOVON  switch  equipment  status 
leads. 

6. 2. 3. 1. 1 AUTOVON  Switch  Register  Memory 

The  register  memory  contents  can  be  obtained  via  the  Traffic  Data  Collection 
System  IB  circuit.  The  data  from  register  memory  consists  of  ten  words,  49  bits 
in  length  of  which  9 bits  can  be  used  to  provide  register  junctor  and  individual  word 
numbers.  The  other  40  bits  of  each  word  provides  a running  status  of  the  call 
being  processed  by  a particular  register  junctor.  The  output  of  the  IB  circuit  can 
then  be  buffered  and  routed  to  level  converter  circuits  before  being  presented  to 
multiplexer  circuits  for  separation  into  processor  words,  16  bits  in  length.  A 
functional  block  diagram  of  the  register  interface  is  shown  in  Figure  6.  2-4. 

6.  2. 3. 1.  2 AUTOVON  Switch  Equipment  Status 

The  equipment  status  can  be  obtained  from  the  AUTOVON  Switch  Status 
Monitor  Interface  (SMI)  circuit.  The  data  available  from  the  SMI  circuit  consists  of 
234  equipment  status  conditions.  The  proposed  outputs  of  the  SMI  circuit  will  have 
to  be  isolated  from  the  ACAS  and  TDCS  outputs  by  correed  drivers  or  high  impedance 
circuits.  The  status  lead  conditions  will  tiien  have  to  be  routed  through  level 
converters  before  being  presented  to  multiplexer  circuits  for  separation  into 
processor  words,  16  bits  in  length.  A functional  block  diagram  of  the  equipment 
status  interface  is  shown  in  Figure  6. 2-5. 

6.2. 3. 2 Additional  Interface  Requirements 

An  interface  to  the  AUTOVON  Switch  Read  Buffer  and  Address  Generator 
(trunk  scanner  sections)  circuits  is  required  to  provide  the  AUTOVON  Switch  Station 
Level  module  with  information  to  maintain  an  up-to-date  status  of  each  line  or  trunk 
circuit.  The  interface  will  consist  of:  expansion  of  the  TDCS  IB  circuit  by  the 
addition  of  55  flip  flops  (FF's),  level  converter  and  multiplexer  circuits.  A total  of 


SMI  CIRCUIT 

Logic  A,B,C 
Out-of-Service 

Memory  X,Y 
Out-of-Service 

System  Stop  Clock 

Comparator  Manual  Mode 

Switch  Marker  A,B 
Out-of-Service 

DSA  Marker  A,B 
Out-of-Service 

Manual  Class-of-Service 
A,B,C  Implemented 

Register  Junctors  1-24 
Maintenance  Busy 

Receivers  1-15 
Maintenance  Busy 

Transceivers  1-15 
Maintenance  Busy 


Receivers  1-15 
Service  Busy 

Transceivers  1-15  Service 
Busy  - Receive  Mode 

Transceivers  1-15  Service 
Busy  - Transmit  Mode 

Transceivers  1-15  Service 
Busy  - Tandem  Mode 

Registers  1-24 
Service  Busy 

Registers  1-24  Service  Busy 
Dial  Pulse  Transmit 

Registers  1-24  Service  Busy 
Dial  Pulse  Receive 

Automatic  Traffic 
Overload  Protection 

All  Register 

Junctors  Busy 

All  Receivers  Busy 

All  Transceivers  Busy 

Trunk  Group 
Busy 
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Figure  6.2-5.  Equipment  Status  Interface  Functional  Diagram 
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55  leads  from  the  Read  Buffer  and  Address  Generator  circuits  will  be  required  to 
present  the  address  and  data  for  each  trunk  scanner  word  to  the  IB  circuit.  The 
address  (15  bits)  will  be  used  by  the  processor  to  control  the  temporary  storage  of 
data.  The  data  which  consists  of  40  bits  of  information  will  provide  the  identification 
(trunk  group,  trunk  tens,  and  trunk  units)  for  each  line  or  trunk  in  the  AUTOVON 
switch.  The  "trunk  unit"  data  (Busy  Idle  Indicator)  consists  of  a four  bit  hexadecimal 
code  used  to  indicate  current  status  of  a particular  line  or  trunk  (idle,  originating 
busy,  maintenance  busy,  and  precedences  of  routine  priority  immediate  flash  or  flash 
override).  A functional  diagram  of  the  Trunk  Scanner  Interface  is  shown  in  Figure 
6.2-6. 


6.2.4  Data  Base  Storage  Requirements 
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The  data  base  storage  requirements  for  the  AUTOVON  Switch  Level  module  are 
presented  below. 


6.  2. 4. 1 Register  Memory 


Each  register  junctor  will  require  31  processor  (16  bits)  words  of  memory 
storage  space  for  data  input  buffering.  This  area  must  be  sized  for  a maximum  of 
24  junctors  which  equates  to  a total  of  744  words. 


6. 2. 4.  2 Disk  Storage 

• i 


Storage  requirements  are  as  follows: 
Trunk  Scanner  (Line  and  Trunk  Status) 


30  Words  x 100  Groups 

3, 300  words 

Call  in  Progress  Registers 

Route  Sequence  Blockage 

4 Words  x 30  Route  Sequences 

Route  Number  Blockage 

4 Words  x 100  Route  Numbers 

Trunk  Group  Blockage 

4 Words  x 100  Trunk  Groups 

120  words 

400  words 

400  words 

Area  Routing  Tables 

6 words  x 100  NNX/NYX  Codes 

600  words 

Busy  Idle  Status  Summary  Registers 

2 words  x 100  Trunk  Groups 

200  words 
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Figure  6.  2-6.  Trunk  Scanner  Interface  Functional  Diagram 


Magnetic  tape  storage  will  be  required  for  journaling  data  from  the  call  in 
progress  and  call  blockage  registers  in  a format  from  which  data  summaries  can 
easily  be  extracted. 

An  intermediate  disc  journal  for  high  speed  access  to  the  previous  one  hour's 
trunk  usage  may  be  necessary,  and  the  size  can  be  calculated  at:  5 calls/secofid 
X 2 registers/call  X 12  words/register  X 3600  seconds/hour  = 432,000  16-bit 
words  for  one  hour  storage. 

6.2.5  AUTOVON  Switch  Station  Level  Module  Software  Considerations 

During  the  preliminary  software  design  the  AUTOVON  switch  station  level 
module,  the  functions  to  be  performed  were  analyzed  and  software  routines  identified. 
A program  hierarchy  was  derived  by  placing  the  routines  into  the  appropriate  level 
of  the  hierarchy.  The  first  paragraph  explains  this  process  in  greater  detail.  The 
second  paragraph  addresses  the  routine  sizing  and  processor  memory  requirements. 
The  routines  are  estimated  in  terms  of  lines  of  code  and  program  and  data  occupancy 
requirements.  The  processor  memory  requirements  are  based  on  an  overlay 
structure  which  was  developed  to  minimize  the  amount  of  core  memory  required  for 
the  applications  programs. 

6. 2. 5. 1 AUTOVON  Module  Station  Level  Hierarchy 

During  the  design  certain  software  functions  were  identified.  These  functions 
were  broken  down  into  routines  and  placed  into  a program  hierarchy  containing  six 
levels.  As  part  of  this  process,  the  following  rules  pertaining  to  hierarchical 
structures  were  observed.  In  a calling  sequence,  a given  routine  may  only  call 
routines  located  on  lower  hierarchical  levels.  This  ensures  a controlled  downward 
flow  of  software  logic  from  one  level  to  another.  Also  routines  possessing  similar 
capabilities  and  functions  should  reside  at  the  same  level  in  the  hierarchy. 


The  software  hierarchy  for  the  AUTOVON  module  station  level  is  shown  in 


Figure  6.  2-7. 


The  highest  level  of  the  hierarchy  contains  the  VON  MODULE  SUPERVISOR 
which  controls  the  execution  of  all  of  the  scheduled  events  in  the  software  system. 

The  second  level  contains  the  I/O  drivers  and  message  processors.  Included  as 
a part  of  this  group  are  the  interrupt-driven  Node  and  CRT  I/O  DRIVERS  and  the  Oper- 
ator and  Node  MESSAGE  PROCESSORS.  Also,  a processor  to  handle  the  input  from  the 
Diagnostic  Processor  is  included  in  this  level.  The  message  processors  supervise  the 
message  decoding  and  then  invoke  the  appropriate  function  overlay  structure. 

The  next  lower  level  contains  the  four  routines  which  are  responsible  for 
performing  the  major  operations  of  the  AUTOVON  Switch  Station  level  module.  These 
operations  include  supervising  call  efficiency,  terminating  trouble,  call  blockage  and 
journal  processing  functions. 

The  fourth  level  of  the  hierarchy  contains  routines  which  support  the  operational 
routines  on  the  previous  level.  The  call  efficiency  routine  on  the  third  level  is  supported 
by  the  following  fourth  level  routines:  ALL  RECEIVE  EQUIPMENT  BUSY,  PARTIAL/ 

NO  DIGIT  PROCESSOR,  ORIGINATING  CONGESTION  PROCESSOR,  ATPC  BLOCKAGE 
PROCESSOR  and  TRANSLATOR  TROUBLE  PROCESSOR.  The  JOURNAL  INPUT  MANAGER 
and  the  JOURNAL  OUTPUT  MANAGER  support  the  journal  processor  on  the  previous  level. 
Thus  the  functional  support  software  minimizes  duplication  of  software  by  providing  a 
level  of  separation  between  the  major  functional  routines  and  the  lower  level  support 
provided  by  levels  five  and  six. 

The  fifth  level  contains  such  routines  as  the  EFFICIENCY  COMPUTATION  which 
supports  the  five  call  efficiency  processing  routines  on  the  fourth  level,  the  VON  MODULE 
FILE  MANAGER  which  controls  access  to  the  VON  module  file,  the  DISPLAY  GENERATOR 
which  supervises  the  generation  of  CRT  displays  for  the  operator,  the  DISPLAY  FILE 
MANAGER  which  provides  access  to  the  file  containing  preformatted  skeleton  CRT 
displays,  and  the  COMMUNICATIONS  MESSAGE  FORMATTER  which  prepares  system 
messages  for  transmission. 

The  lowest  level  provides  six  very  basic  routines  which  support  the  system 
activities.  These  routines  include  message  type  decoding,  error  processing,  I/O 
buffer  management  and  journal  blocking. 
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6. 2. 5. 2 Software  Sizing 

This  paragraph  addresses  the  software  sizing  of  the  AUTOVON  Switch  Station 
Level  Module.  As  a part  of  the  design  process,  the  software  routines  were  identified 
and  estimated  as  to  the  number  of  lines  of  code  and  also  the  program  and  data 
occupancy  requirements  were  addressed.  An  overlay  structure  was  then  developed 
to  decrease  the  processor  memory  requirements. 

The  program  sizing  is  based  on  an  estimation  of  the  number  of  lines  of  HOL 
code  required  to  implement  each  routine  identified  in  the  AUTOVON  Switch  Station 
Level  Module  hierarchy  (Paragraph  6.2.5. 1)  and  additional  memory  requirements  to 
accommodate  data  for  each  of  these  routines.  The  sizing  includes  applications 
software  and  operating  system  modifications/enhancements  only  and  assumes  that 
the  host  computer  supplies  the  necessary  support  software. 

The  support  software  required  includes  a basic  operating  system  with  an 
overlay  linker/loader,  a task  manager  to  control  the  swapping  of  programs  from 
secondary  storage  and  a capable  file  manager  supporting  the  programs  and  data  storage 
on  disk.  For  program  development,  an  HOL  compiler  (i.  e.  FORTRAN,  COBOL, 

PL/I)  is  needed  along  with  a text  editor  and  an  assembler. 

The  VON  Module  program  sizing  at  the  switch  level  is  shown  in  Table  6.  2-1. 

The  program  occupancy  for  each  routine  is  based  on  an  expansion  ratio  of  15  bytes 
of  storage  for  each  line  of  HOL.  This  ratio  is  typical  of  16-bit  word  length  machines 
using  currently  available  HOL  compilers.  Section  1.4  provides  further  justifica- 
tion for  this  expansion  ratio.  For  the  I/O  driver  routines  and  the  call  efficiency 
processing  routine  the  data  occupancy  includes  buffer  and  table  space  needed  by  those 
routines.  The  total  memory  requirement  for  the  VON  Module  Station  Level  applica- 
tion software  is  44K  bytes  without  the  use  of  overlays. 

Since  the  software  system  described  above  is  functionally  partitionable,  it  is 
applicable  to  incorporate  it  into  an  overlay  structure.  The  use  of  overlays,  where 
on-line  secondary  storage  capabilities  are  available,  minimizes  processor  memory 
requirements  by  retaining  the  low  demand  software  on  disk. 
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AUTOVON  Station  Level  Module  Sizing  Summary 


An  overlay  structure  for  the  VON  module  software  at  the  switch  level 
was  developed  by  separating  the  routines  contained  in  the  program  hierarchy  into 
functions.  Table  6.  2-2  summarizes  the  overlay  structure.  These  overlays  perform 
set  functions  such  as  journal, call  efficiency,  terminating  trouble,  call  blockage 
processing  and  operator  interaction.  Depending  on  the  function  to  be  performed, 
only  one  of  these  overlays  would  be  in  memory  at  any  time. 

In  order  to  determine  the  amount  of  memory  required  for  applications  soft- 
ware, it  is  necessary  to  add  all  of  the  memory  requirements  for  the  routines  which 
support  a given  function.  Table  6.2-2  shows  that  the  largest  memory  requirement 
occurs  for  processing  call  efficiency.  In  this  case  the  applications  software  requires 
28,068  bytes  of  main  memory.  This  sizing  is  only  for  the  applications  programs  and 
relies  on  a host  computer  for  the  support  software.  Thus,  the  total  memory  require- 
ments for  the  AUTOVON  Switch  Level  Module  has  been  determined  to  be  28K  bytes. 

6.2.6  Desired  Data  Outputs 

AUTOVON  switch  level  module  outputs  should  include  flags  and  trouble 
indicators  to  the  node  for  correlation  with  transmission  status  for  detection  of  link 
or  trunk  problems  which  may  be  preventing  call  completion  by  the  AUTOVON  switch. 

Outputs  to  the  ACOC  Level  AUTOVON  Module  should  include  switch  trouble 
indicators,  trunk  trouble  indicators  and  traffic  overload  conditions  for  use  by  the 
ACOC  program  in  recommending  remedial  actions  by  the  ACOC  controller  for 
alleviating  overload  conditions  on  the  network. 

The  proposed  outputs  from  the  AUTOVON  switch  level  module  follow: 

a.  Percent  of  call  processing  efficiency  by  Register  Junctor*. 

b.  Percent  of  call  processing  efficiency  by  Switch  *. 

♦To  appropriate  processing  module  on  un:  atisfactory  threshold  detection 
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AUTOVON  Switch  Level  Module  Processor  Function  Sizing  Summary 
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c.  Flags  and  Trouble  indicators  for: 

1.  Originating  Trunk  Trouble 

(a)  Interswitch  trunk  and  partial  or  no  digits  received** 

(b)  Class  mark  lookup  and  translator  trouble 

(c)  Precedence  blocked  by  translator  trouble  flagged  by  precedence 
level  and  originating  trunk 

(d)  Pool  equipment  overload  during  origination 

(e)  Special  Interest  Indicator 

2.  Terminating  Trunk  Trouble 

(a)  No  start  after  trunk  selection** 

(b)  Time  out  during  dialing  out  by  switch** 

(c)  Call  durations  of  less  than  a threshold  time  on  dial  pulse 
terminating  trunks** 

(d)  Special  Interest  Indicator 

3.  Pool  Equipment  Overloads 

(a)  MF  2/6  Transceiver  overload  when  call  processing  efficiency 
is  below  threshold* 

(b)  TCMF  receiver  overload  when  processing  efficiency  is  below 
threshold* 

(c)  Line  Load  control  by  class,  ATOP  and  ARB  commands 

(d)  Pool  equipment  assignment  trouble  when  call  processing 
efficiency  is  below  threshold* 

6. 2. 6. 1 Output  Development 

The  following  is  an  explanation  of  the  development  of  the  above  listed  outputs. 

a.  Call  processing  efficiency  can  be  determined  by  comparing  the  number  of 
successfully  terminated  calls  with  the  number  of  originated  calls. 

An  origination  is  assumed  when  the  register  junctor  exits  from  Processor 
Control  Sequence  State  DCX  1 to  DCX  2. 

* To  appropriate  processing  module  on  unsatisfactory  threshold  detection 
**  To  node  for  correlation 


A termination  is  assumed  when  the  register  junctor  exits  from  DCX  35 
to  DCX  36. 


A call  is  assumed  to  be  completed  successfully  regardless  of  the 
terminating  trunk  unless  one  of  the  following  conditions  causes  the  call 
to  be  terminated  to  an  announcement  or  tone  trunk: 

(1)  Translation  Instruction  20  (Operating  Equipment  Irregularities) 

(2)  Translation  Instruction  25  (No  Dialed  Digits)  and  an  Originating 
Interswitch  Trunk 

(3)  Translation  Instruction  26  (Partial  Digits)  and  an  Originating 
Interswitch  Trunk 

(4)  Calls  terminated  to  the  29xx  Trunk  Group  (Switch  Isolated  by  ATPC 
Plan) 

Calls  attempted,  but  blocked  by  a failure  to  clear  both  switch  markers  prior 
to  the  processor  exit  to  DCX2  will  be  considered  call  attempts,  but  because  there 
will  be  no  final  disposition  of  the  call  in  common  control,  it  will  be  considered  an 
incomplete  connection.  Many  of  the  outputs  depend  upon  reaching  appropriate 
thresholds.  The  threshold  values  included  are  approximations,  and  can  easily  be 
changed  to  accommodate  more  realistic  thresholds  if  experience  dictates  the  initial 
threshold  to  be  unrealistic. 

By  products  of  the  computations  and  comparisons  required  for  calculating  call 
processing  efficiency  will  be  the  ability  to  determine  many  of  the  other  listed  over- 
load and  trouble  conditions.  A few  additional  processing  steps  are  required,  but 
each  will  result  in  an  output  flag  and  indicator  to  the  Node  or  ACOC  processing 

[ i 

module,  and  in  some  instances  to  the  diagnostic  processor  for  further  correlation 
and  display  where  necessary  to  the  appropriate  level  of  control. 

| Since  the  ability  to  make  control  decisions  rests  with  the  ACOC  Network 

Controller,  data  reduction  and  suggested  control  actions  involving  more  than  one 
switch  will  be  accomplished  at  that  level.  In  the  few  instances  where  a control 
action  can  be  suggested  on  the  basis  of  data  collected  from  one  switch,  a flag  to 
that  effect  will  be  transmitted  to  the  ACOC  along  with  the  trouble  or  overload  message. 
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The  percentage  of  call  processing  efficiency  is  the  key  to  reporting  most 
overload  and  troubles  from  each  switch,  i.e.,  if  the  switch  is  satisfactorily 
terminating  all  calls  except  low  precedence  (Priority  or  Routine)  there  is  no  reason 
to  impose  controls  to  alleviate  the  congestion. 

A separate  routine  will  address  blockage  of  immediate  or  higher  precedence 
calls,  and  will  give  the  network  controller  visibility  of  these  conditions. 

6.  2. 6.  2 Flowcharts 

The  flowcharts  developing  the  AUTOVON  switch  level  module  functions  are 
described  in  the  following  paragraphs.  Abbreviations  used  in  these  flowcharts  are 
explained  in  Table  6.  2-3. 

6. 2. 6. 2. 1 Call  Processing  Efficiency 

This  algorithm  develops  the  following  outputs: 

• Switch  Call  Processing  Efficiency  Percentage 
(If  Requested) 

(If  Degraded) 

• Individual  Register  Junctor  Call  Processing  Efficiency  Percentage 
(If  Requested) 

(If  Degraded) 

• MF  Transceiver  Equipment  Overload 

• TCMF  Receiver  Equipment  Overload 

• Assigner  Problem  (To  Diagnostic  Processor) 

• Assigner  Problem  (To  ACOC  If  Call  Processing  is  Degraded) 

• Originating  Interswitch  or  Special  Interest  Circuit  Problem  (To  Node) 

• Access  of  ATPC  Plan  #2  Routing 

• Originating  Congestion 
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Table  6.  2-3.  Flowchart  Abbreviations 

DCX  - Decoded  CX  (Process  Control  Sequence  State) 

T.I.  - Translation  Instruction 
Tk  - Trunk 

LO  - Lock  Out  (Command  to  Switch  Marker) 

TT  - Identifies  Originator  as  Using  DTMF  (TCMF)  Address  Signaling 

TAMFB  - All  MF  Transceivers  Busy 

TATTB  - All  TCMF  Receivers  Busy 

ATPC  - Automatic  Traffic  Plan  Control 

Plan  It  1 - Code  Cancellation  (Deletes  Automatic  Alternate  Routes) 
Plan  It  2 - Code  Isolation  (Routes  calls  of  affected  dialed  digits  to 
Isolated  Code  Announcement) 


Dialed  Precedences 
3 - Priority 
2 - Immediate 
1 - Flash 

0 - (Binary  10)  Flash  Override 


1 


PMB  - Pilot  Make  Busy 

ATOP  - Automatic  Traffic  Overload  Protection  locks  out  from  call  origination 
all  trunks  provided  with  Line  Load  Control  strapping.  This  occurs 
when  a threshold  of  number  of  busy  Register  Junctors  is  exceeded.  The 
threshold  is  set  by  a switch  at  the  Maintenance  Console. 

ARB  - All  Register  Junctor  Busy  - This  control  prevents  any  incoming 
calls  from  being  recognized  by  the  Switch  Markers. 


I 
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LLC  A,  B,  C - Line  Load  Control,  A,  B,  or  C.  Strapping  that  allows  trunks 
to  be  locked  out  from  call  origination  in  three  sets.  Set  A,  Set  B 
and  Set  C.  This  control  is  manually  imposed. 


SS  - Switch  Marker  Sequence  State 


Automatic  Traffic  Overload  Protection 
All  Register  Junctor  Busy 


Line  Load  Control  A,  B,  or  C 


The  Call  Processing  algorithm  is  divided  into  the  following  specific  subroutines: 

• General 

• All  Receive  Equipment  Busy 

• Partial  or  No  Digits 

• Originating  Congestion 

• ATPC  Blockage 

• Compute  Percent  Efficiency 

• Translator  Trouble 

a.  The  General  Subroutine,  Figure  6.2-8,  collects  call  attempts,  call 
completions  and  call  blockages  by  counting  the  processing  flow  through 
appropriate  call  processing  sequence  states  and  development  of  the 
translation  instruction  which  indicates  call  blockages. 

b.  The  All  Receive  Equipment  Busy  Subroutine,  Figure  6.2-9,  isolates  the 
cause  of  blockage  indicated  by  equipment  operating  difficulty  indications, 
and  sends  the  appropriate  message  to  the  appropriate  level  of  control. 

c.  The  Partial  or  No  Digit's  Subroutine,  Figure  6.2-10,  isolates  the  dialing 
of  partial  addressing  digits  by  automatic  equipment  or  special  interest 
circuits  to  the  path  over  which  the  partial  digits  are  received,  and  reports 
originating  trunk  trouble  to  the  node. 

d.  The  Originating  Congestion  Algorithm,  Figure  6.  2-11,  determines  an 
overload  of  calls  awaiting  dialed  digits  an  abnormally  long  time  (10 
seconds),  and  sends  originating  trunk  trouble  messages  to  the  Node  for  all 





circuits  in  this  status  at  the  end  of  that  time.  This  subroutine  also 
determines  automatic  traffic  overload  protection,  all  register  junctors 
busy,  line  load  control  conditions,  and  call  attempts  represented  by  calls 
blocked  through  switch  marker  failure. 

e.  The  ATPC  Blockage  Subroutine,  Figure  6. 2-12,  reports  accesses  to 
ATPC  Code  2 announcement  to  the  switch  and  ACOC. 

f.  The  Compute  Percent  Efficiency  Subroutine,  Figure  6.2-12,  calculates 
the  call  processing  efficiency  of  each  register  junctor  using  call  attempt, 
call  completion,  and  call  blockage  data  from  the  General  Subroutine,  and 
sends  percentage  to  requesters  or  to  the  appropriate  level  of  control  if 
the  efficiency  does  not  exceed  a degradation  threshold. 

g.  The  Translator  Trouble,  Figure  6.2-13,  interleaves  with  the  Call 
Blockage  Algorithm  in  maintaining  call  blockage  by  precedence,  and 
notifies  the  diagnostic  processor  of  translator  troubles  indicated  by 
abnormal  call  processing  sequence  state  changes  not  normally  detected 
by  the  switch  diagnostics. 

6. 2. 6.  2. 2 Terminating  Trouble  Indicator 

This  algorithm  develops  the  following  outputs: 

• Flag  and  Trunk  Identity  to  Nodal  Processor 

• Flag  indicating  an  Overload  in  a Connecting  Tandem  Switch 

Call  processing  trouble  reports  indicating  probable  transmission  system 
problems  or  distant  switch  overloads  are  received  from  the  AUTOVON  switch 
diagnostic  processor.  A correlation  of  the  trouble  report  with  register  junctor  data 
is  followed  by  a test  of  the  alternate  routing  counter. 

If  the  alternate  route  counter  is  not  at  the  overload  point,  the  terminating 
trunk  identity  is  sent  to  the  nodal  processor  for  correlation  with  known  system 
problems. 
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Figure  6.2-8.  Call  Processing  Efficiency  - General  (Sheet  1 of  3) 


Figure  6.  2-8. Call  Processing  Efficiency  - General  (Sheet  2 of  3) 
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• Variable  thresholds  to  be  initially  set  during  programming  phase. 
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Figure  6.  2-9.  Call  Processing  Efficiency  - All  Receive  Equipment 
Busy  Subroutine  (Sheet  1 of  2) 
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Figure  6.2-11.  Call  Processing  Efficiency  - Originating  Congestion 

(Sheet  2 of  2) 
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Figure  6.2-12.  Call  Processing  Efficiency  - ATPC  Blockage  Subroutine 
and  Compute  % Efficiency  Subroutine  (Sheet  1 of  2) 
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Figure  6.3-12.  Cali  Processing  Efficiency  - ATPC  Blockage  Subroutine 
and  Compute  % Efficiency  Subroutine  (Sheet  2 of  2) 
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Figure  6w  3-13.  Call  Processing  Efficiency  - Translater  Trouble  Subroutine 


If  the  overload  counter  is  at  the  overload  point,  a test  of  the  call  processing 
sequence  state  is  made  to  determine  if  the  first  tandem  switch  is  the  cause  of  the 
overload  indication.  If  so,  a flag  indicating  this  overload  is  sent  to  the  ACOC  along 
with  correctable  data. 

6.2. 6.  2.3  Call  Blockage  Indicator 

This  algorithm,  shown  in  Figure  6.2-15,  develops  the  following  Call  Blockage 
Messages  for  transmission  to  the  ACOC: 

• Originating  Immediate  or  Higher  Precedence  Blockage 

• Tandem  Immediate  or  Higher  Precedence  Blockage 

• Terminating  PBX  with  Immediate  or  Higher  Precedence  Blockage 

• All  Trunks  Busy  and  Receiving  Too  Many  Calls  from  a Connecting  Switch 

• Too  Many  Calls  Being  Alternate  Routed  from  This  Switch  to  A Connecting 
Switch  (Message  includes  the  affected  NNX/NYX  codes) 

The  initial  blockage  indicator  development  is  limited  to  precedence  call 
blockage.  The  precedence  blockage  is  determined  by  detection  of  a Translation 
Instruction  (T.I.)  21.  After  detection  of  the  T.  I.  21,  the  dialed  precedences  are 
determined  and  stored  in  call  blockage  registers.  Immediate  and  higher  precedences 
are  separated  from  Priority  precedence  for  determination  of  Immediate  or  higher 
blockage.  Call  routing  is  then  determined  by  searching  the  routing  tables  for  the 
normal  terminating  trunk  groups.  These  trunk  groups  are  then  separated  by  type 
(inter-switch  and  PBX).  The  originating  trunk  identity  is  sampled  and  correlated 
with  the  normal  terminating  trunk  group  to  determine  if  the  call  was  to  have  been 
a tandem  call. 

If  the  terminating  trunk  group  is  a PBX  group,  and  the  precedence  is 
Immediate  or  Higher,  the  PBX  is  flagged  as  blocking  Immediate  or  higher  preced- 
ence calls.  If  the  originating  trunk  group  and  terminating  trunk  group  are  both 
inter-switch  trunk  groups,  and  precedences  blocked  are  Immediate  or  higher,  the 
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Figure  6. 2-14.  Terminating  Trouble  Indicator 
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Figure  6.2-15.  Call  Blockage  Indicator  (Sheet  2 of  2) 
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call  is  flagged  as  Tandem  Immediate  or  higher  precedence  blockage.  The  connecting 
switches,  and  the  NNX/NYX  code  being  blocked  are  included  in  the  blockage  message 
to  the  ACOC.  If  the  originating  trunk  group  is  not  an  inter-switch  trunk  group,  and 
the  precedence  is  Immediate  or  higher,  the  call  is  flagged  as  Originating  Immediate 
or  higher  precedence  blockage. 

The  All  Trunks  Busy  condition  is  then  sampled  for  affected  inter-switch  trunk 
groups.  The  Call  in  Progress  Registers  of  these  inter-switch  trunk  groups  are  then 
sampled  to  determine  the  ratio  of  originating  to  terminating  calls  now  standing. 

If  over  60  percent  of  the  calls  are  determined  to  be  originating,  a flag  to  the 
ACOC  is  generated  indicating  too  many  calls  are  being  received  from  the  connecting 
switch  represented  by  the  overloaded  trunk  group.  If  over  60  percent  of  the  calls 
are  determined  to  be  terminating,  and  the  percent  of  calls  not  on  their  primary 
trunk  group(s)  is  greater  than  (a  programmed%),  a flag  to  the  ACOC  is  generated 
indicating  too  many  calls  are  being  alternate  routed  from  the  reporting  switch  via 
the  connecting  switch  to  — NNX/NYX  codes. 

If  the  ratio  of  originating  to  terminating  calls  on  the  overloaded  inter- switch 
trunk  groups  is  between  40  and  60%,  a flag  to  the  ACOC  will  be  generated  indicating 
All  Trunks  Busy  between  the  reporting  switch  and  the  connecting  switch  represented 
by  the  overloaded  trunk  group(s). 

NOTE:  The  originating  to  terminating  ratio  thresholds  will  have  to  be  assigned 
after  study  of  the  normal  traffic  routing  for  the  time  of  day  and  day  of  week. 

6.2. 6.  2.4  Busy  Idle  Status  Summary 

The  AUTOVON  Switch  Level  Module  Busy  Idle  Status  Summary  Algorithm, 
Figure  6.2-16,  consists  of  routines  to  read  the  Call-in-Progress  register  and 
extract  Trunk  Identification  and  Status  Data.  This  data  will  then  be  summarized 
by  trunk  group  and  status.  The  ACOC  AUTOVON  module  can  request  this  data  on 
an  as  required  basis. 
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6. 2. 6. 2. 5 Pool  Equipment  Status 

This  algorithm.  Figure  6.  2-17,  produces  the  following  flags  and  information: 

• Pool  Equipment  Maintenance  Busy  Status  on  Manual  Request 

• A Flag  for  Incorrect  Automatic  Traffic  Overload  Protection  (ATOP)  Switch 
Setting 

• A Flag,  Number  and  Percent  of  Register  Junctors  Maintenance  Busy  upon 
reaching  a threshold  of  Busy  Register  Junctors 

• A Flag,  Number  and  Percent  of  TCMF  Receivers  Maintenance  Busy  upon 
reaching  a threshold  of  Busy  TCMF  Receivers 

• A Flag,  Number  and  Percent  of  MF  2/6  Transceivers  Maintenance  Busy 
upon  reaching  a threshold  of  Busy  MF  2/6  Transceivers 

Upon  receipt  of  pool  equipment  maintenance  busy  status,  a test  is  made  for 
manual  requests.  If  one  is  waiting,  the  number  and  percent  of  each  type  pool  equip- 
ment in  maintenance  busy  status  is  calculated  and  a message  containing  the  requested 
data  is  transmitted  to  the  requester. 

If  no  manual  requests  are  being  serviced,  a test  is  made  for  a threshold 
number  of  register  junctors  busy.  If  the  threshold  is  exceeded,  a test  is  made  for 
ATOP.  If  ATOP  is  not  true,  a test  is  made  for  all  Registers  Busy  (ARB).  If  ARB 
is  true,  a flag  indicating  ATOP  switch  setting  incorrect  is  sent  to  the  ACOC  and 
diagnostic  processor.  Regardless  of  the  results  of  ATOP  and  ARB,  a calculation 
of  the  number  and  percent  of  register  junctors  maintenance  busy  is  made  and  the 
results  are  forwarded  to  the  ACOC. 

After  the  register  junctor  calculations  are  completed,  a test  for  the  number  of 
TCMF  Receivers  busy  is  made.  If  the  number  busy  exceeds  a threshold,  a calculation 
of  the  number  and  percent  of  TCMF  Receivers  maintenance  busy  is  made  and  the 
results  are  forwarded  to  the  ACOC. 
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Figure  6.2-17.  Pool  Equipment  Status 
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After  the  TCMF  Receiver  calculations  are  completed,  a test  for  the  number  of 
MF  2/6  Transceivers  busy  is  made.  If  the  number  busy  exceeds  a threshold,  a 
calculation  of  the  number  and  percent  of  MF  2/6  Transceivers  maintenance  busy  is 
made  and  the  results  are  forwarded  to  the  ACOC. 

6. 2. 6.  2. 6 Equipment  Status 

This  algorithm,  shown  in  Figure  6.2-18,  provides  the  following  outputs: 

• Equipment  Status  upon  Manual  Request 

• Equipment  Status  to  ACOC  when  call  processing  efficiency  is  below  a 
threshold 

The  appropriate  equipment  status  is  transmitted  to  either  the  ACOC  or 
requester  under  the  following  conditions: 

a.  To  Requester; 

If  any  equipment  is  out  of  service  or  ATOP  and  Line  Load  Control  are  not 
in  effect 

b.  To  the  ACOC  Automatically: 

If  any  equipment  is  out  of  service  or  ATOP  or  Line  Load  Control  is  in 
effect  provided  call  processing  efficiency  is  below  a threshold 

6.3  AUTOVON  SWITCH  ACOC  LEVEL  MODULE 

The  ACOC  level  module  will  accept  automatic  inputs  from  the  individual  switch 
modules  via  the  route  provided  by  the  Node-Sector-ACOC  data  communications 
channel.  This  module  will  also  have  the  capability  to  automatically  request  other 
data  stored  by  the  individual  switch  station  level  modules  as  needed  for  further 
processing  and  correlation. 
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Figure  6.2-18.  Equipment  Status 
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6.3.1  Input  Sources 

The  automatic  inputs  to  the  AUTOVON  ACOC  module  will  be  limited  to  the 
automatic  inputs  from  each  Node  and  AUTOVON  switch  station  level  module  under 
ACOC  control.  Manual  inputs  to  request  or  suppress  displays  and  record  control 
actions  will  be  accepted. 

6.3.2  Input  Data 

The  input  data  at  the  ACOC  level  will  consist  of  abnormal  traffic  or  equipment 
conditions  supplied  from  the  Nodes  and  individual  AUTOVON  switch  station  level 
modules. 

Currently,  the  inputs  from  the  nodes  are  seen  as  trunk  troubles  reported  to  the 
Node  by  an  AUTOVON  switch  station  level  module.  Inputs  from  the  AUTOVON  switch 
station  level  modules  which  have  been  developed  are  listed  with  their  message  codes 
in  Table  6.3-1.  Additional  inputs  will  be  developed  as  the  need  is  determined. 

Each  message  will  contain  an  addressee  code,  message  code  and  transmitting 
switch  code.  Figure  6.3-1  illustrates  the  message  structure.  If  the  most  significant 
digit  of  the  message  code  is  a "0",  more  data  will  follow.  Each  of  the  following  data 
characters  will  consist  of  an  8-bit  Type  Data  Code  and  up  to  16  data  bits.  Suggested 
type  data  codes  and  data  codes  for  use  in  data  messages  are  included  in  Tables 
6.3-2  through  6.3-9.  The  make  up  of  messages  as  presently  envisioned  is  included 
as  Table  6.3-10. 

6.3.3  ACOC  Data  Outputs  and  Displays 

The  AUTOVON  module  at  the  ACOC  in  conjunction  with  other  related  unified 
control  modules  should  provide  the  network  controllers  with  visibility  of  network 
operational  conditions  and  status,  traffic  congestion,  and  allow  for  network  control 
decisions  and  actions  to  be  made  and  implemented  on  a timely  basis.  The  initial 
correlation  and  display  of  data  should  be  at  a manageable  level  and  expanded  or 
reduced  based  on  network  operational  experience  over  a period  of  use  under  all 
types  of  conditions.  The  following  list  of  displays  are  considered  adequate  for 
initial  implementation. 
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6. 3. 3. 1 Required  Outputs 

The  list  of  switch  conditions  providing  visibility  should  be  displayed  to  the 
network  controller  as  follows: 

• Equipment  Status  - Logics  Out -of-Ser vice 

Memory  Out-of-Service 
Markers  Out-of-Service 

These  items  are  to  be  displayed  only  if  call  processing  is  adversely 
affected. 

• Traffic  Overloads  - All  trunks  busy,  tandem  blockage,  precedence 
blockage,  etc.  To  be  displayed  if  system  congestion  appears  imminent. 

• All  calls  routed  by  ATPC  Plan  #2  if  the  plan  has  not  been  ordered  by  the 
ACOC  controller. 

• Originating  and  terminating  line  or  trunk  circuit  problems  affecting 
special  interest  circuits 

• Summaries  of  any  additional  stored  information  on  :nanual  request 
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Decisions  resulting  from  analysis  of  abnormal  conditions  should  provide  the 
network  controller  with  the  following  suggested  control  actions: 

• Implementation  of  Line  Load  Control  A,  B,  or  C. 

• Implementation  of  alternate  routing  decks  (Red  Decks)  to  circumvent  a 
transmission  system  that  is  inoperative 

• Implementation  of  directionalization  and  identification  of  trunk  or  trunk 
group  requiring  that  action. 

• Implementation  of  ATPC  Plans  #1  or  #2  and  dialed  codes  requiring  that 
action. 

6.3. 3.  2 Flowcharts 

The  flowcharts  developing  the  AUTOVON  ACOC  level  module  functions  are 
described  in  the  following  paragraphs. 
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TABLE  6.3-1.  Message  Codes  (Sheet  1 of  2) 


00000001 

(1) 

Terminating  Trunk  Trouble  (Trunk  Identities) 

00000010 

(2) 

Originating  Trunk  Trouble  (Trunk  Identities) 

00000011 

(3) 

DCX-9  Overload  (Trunk  Identities 

00000100 

(4) 

Degraded  Call  Processing  Efficiency  (By  Register  Junctor) 

00000101 

(5) 

Manually  Requested  Register  Junctor  Call  Processing  Efficiency 

10000110 

(6) 

TCMF  Receiver  Overload  on  detection  of  Degraded  Switch  Call 
Processing  Efficiency 

10000111 

(7) 

MF  2/6  Transceiver  Overload  on  detection  of  Degraded  Switch 
Call  Processing  Efficiency 

10001000 

(8) 

ATOP  and  Call  Processing  Efficiency  Invalid 

10001001 

(9) 

Line  Load  Control  A and  Call  Processing  Efficiency  Invalid 

10001010 

(10) 

Line  Load  Control  B and  Call  Processing  Efficiency  Invalid 

10001011 

(11) 

Line  Load  Control  C and  Call  Processing  Efficiency  Invalid 

10001100 

(12) 

All  Registers  Busy 

10001101 

(13) 

ATOP  Switch  Setting  Incorrect 

00001110 

(14) 

Number  and  Percent  of  Register  Junctors  Maintenance  Busy  on 
Threshold  of  Register  Junctors  Busy 

00001111 

(15) 

Number  and  Percent  of  TCMF  Receivers  Maintenance  Busy 
on  Threshold  of  TCMF  Receivers  Busy 

00010000 

(16) 

Number  and  Percent  of  MF  2/6  Transceivers  Maintenance 

Busy  on  Threshold  of  MF  2/6  Transceivers  Busy 

00010001 

(17) 

Pool  Equipment  Status  in  Reply  to  Manual  Request 

10010010 

(18) 

Assigner  Problem  and  Degraded  Call  Processing  Efficiency 

00010011 

(19) 

Degraded  Call  Processing  Efficiency  (By  Switch) 

0 
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Table  6. 3-1.  Message  Codes  (Sheet  2 2) 


00010100 

(20) 

Manually  Requested  Switch  Call  Processing  Efficiency) 

00010101 

(21) 

Too  Many  Calls  Being  Alternated  Routed  From  This  Switch 
(This  Switch  Identity)  to  (Connecting  Switch  Identity)  and 
(NNX  or  NYX  Codes  Affected) 

00010110 

(22) 

ATB  and  Receiving  too  Many  Calls  from  (Connecting  Switch 
Identity) 

00010111 

(23) 

Immediate  Precedence  Blockage  Terminating  to  a PBX  (PBX 
Identity) 

00011000 

(24) 

Immediate  Precedence  Blockage  - Tandem  Traffic  (Originating 
Trunk  Group  and  Terminating  Trunk  Group)  and  affected 

NNX  or  NYX  Codes 

00011001 

(25) 

Excessive  number  of  calls  being  routed  to NNX/NYX 

Codes  on  Trunk  Group 

00011010 

(26) 

Overload  in  first  tandem  Switch  on  route  of  NNX/NYX 

Code  reported. 

00011011 

(27) 

AT  PC  plan  #2  for  NNX/NYX  Code  reported  accessed  at 
reporting  switch. 

00011100 

(28) 

Equipment  out  of  service  status  summary  (on  detection  of 
degraded  call  processing  efficiency) 

00011101 

(29) 

Equipment  status  summary  (Reply  to  manual  request) 

00011110 

(30) 

All  trunks  busy  on  reported  trunk  group 

00011111 

(31) 

General  data  report/request 

00100000 

(32) 

Trunk  Group  busy /idle  status  summary 

00100001 

(33) 

Busy  Idle  Status 
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TABLE  6. 3-2.  Type  Data  Codes  (Sheet  1 of  2) 


00000001 

00000010 

00000011 

00000100 

00000101 

00000110 

00000111 

00001000 

00001001 

00001010 

00001011 

00001100 

00001101 

00001110 

00001111 

00010000 

00010001 

00010010 

00010011 

00010100 

00010101 


(1) 

Originating  Trunk  or  Trunk  Group 

(2) 

Terminating  Trunk  or  Trunk  Group 

(3) 

Call  Processing  Efficiency  and  Register  Junctor  Number 

(4) 

Switch  Call  Processing  Efficiency 

(5) 

TCMF  or  MF  2/6  Equipment  Identity 

(6) 

Register  Junctor  Total  and  Percent 

(7) 

TCMF  Receiver  Total  and  Percent 

(8) 

MF  2/6  Transceiver  Total  and  Percent 

(9) 

This  Switch  Identity 

| (10) 

Connecting  Switch  Identity 

(ID 

NNX  or  NYX  Code 

(12) 

Register  Junctor  1-8  Busy/Maint.  Busy  Status 

(13) 

Register  Junctor  9-16  Busy/Maint.  Busy  Status 

(14) 

Register  Junctor  17-24  Busy/Maint.  Busy  Status 

(15) 

TCMF  1-15  Service  Busy  Status 

(16) 

TCMF  1-15  Maint.  Busy  Status 

(17) 

MF  2/6  1-15  Service  Busy  Status 

(18) 

MF  2/6  1-15  Maint.  Busy  Status 

(19) 

Logic,  Memory,  Marker  Out  of  Service  Status 

(20) 

Trunk/Trunk  Group 

(21) 

PBX  Code 

6-55 

gK  • timk 

Table  6.3-2.  Type  Data  Codes  (Sheet  2 of  2) 


1 


1 

00010110 

(22) 

Time  'Hour*' 

i 

00010111 

(23) 

Time  "Minute  and  Second" 

1 

00011000 

(24) 

Busy  Idle  Status  Summary.  Trunk  Group  ID  Flash  Override 
and  Flash  Count 

? 

| 

00011010 

(25) 

Busy  Idle  Status  Summary  Immediate,  Priority  and  Routine 

Count 

1 

1 

0011011 

(26) 

Busy/ Idle  Indicator 

, 

■ 

i 

1000001 

(27) 

Special  Interest  Originating  Trunk  or  Trunk  Group 

1 ’ 

H ' ; 

1000010 

(28) 

Special  Interest  Terminating  Trunk  or  Trunk  Group 

1 

1 

1 

1 

i 


ji  ! 

5 


•jmm 


TABLE  6.3-3.  Reporting  and  Connecting  Switch  Codes 


Code 

Switch 

0000 

Clark  (CLK) 

0001 

Coltano  (CTO) 

0010 

Corozal  (CZL) 

0011 

Donnersberg  (DON) 

0100 

Feldberg  (FEL) 

0101 

Finegayan  (FGB) 

0110 

Fort  Buckner  (FTB) 

0111 

Fuchu  (FUU) 

1000 

Hillingdon  (HIN) 

1001 

Humosa  (HUM) 

1010 

Langerkopf  (LKF) 

1011 

Martlesham  Heath  (MAM) 

1100 

Mount  Pateras  (MTP) 

1101 

Mount  Vergine  (MTV) 

1110 

Schoenfeld  (SCH) 

1111 

Wahiawa  (WHW) 
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TABLE  6.3-4.  Register  Junctor  (RJ)  Number  Codes 


CODE 


RJ  NUMBER 


00001  1 

00010  2 

00011  3 

00100  4 

00101  5 

00110  6 

00111  7 

01000  8 

01001  9 

01010  10 

01011  11 

01100  12 

01101  • 13 

OHIO  14 

01111  15 

10000  16 

10001  17 

10010  18 

10011  19 

10100  20 

10101  * 21 
10110  22 

10111  23 

11000  24 
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TABLE  6.3-6.  TRUNK,  NNX/NYX  CODES 


ORIGINATING  TRUNK/TERMINATING  TRUNK  CODES 


Code 

Trunk  ID* 

0000 

0000  0000 

0000 

0000 

0000 

0000  0000 

0001 

0001 

Thru 

1001 

1001  1001 

1001 

9999 

* Trunk  ID  is  a 4-digit  code-All  Digits  can  have  the  value  "0" 
thru  "9". 


NYX/NNX  CODES 


NYX 


Code 


Value* 


0010  00Q0  0000 
Thru 

1001  0001  1001 


2 J0 
919 


* - First  Digit  of  NYX  code  can  be  any  digit  r2"  thru  "9" 

- Second  Digit  of  NYX  Code  can  be  digits  "0"  or  "1"  only 

- Third  Digit  of  NYX  Code  can  be  any  digit  "0"  thru  "9" 


NNX 


Code 


Value* 


0010  0010  0000 


thru 

1001  1001  1001 


220 

999 


* - First  and  Second  digit  of  NNX  code  can  be  any  digit  "2"  thru  "9" 
- Third  digit  of  NNX  code  can  be  any  digit  "0"  thru  "9" 
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TABLE  6.3-  7.  Call  Processing  Efficiency,  PABX/PBX,  Busy 
Idle  Indicator  Codes 


SWITCH  OR  JUNCTOR  CALL  PROCESSING  EFFICIENCY  CODES 


0 0000  0000 
thru 

1 0000  0000 


PRIVATE  AUTOMATIC  OR  PRIVATE 


Originating  Busy 
Flash  Precedence 
Immediate  Precedence 
Priority  Precedence 
Routine  Busy 
Queueing  Idle 
True  Idle 
Maintenance  Busy 
Unequipped 


IDENTITY  CODES 

Code 

PABX/PBX 

000001 

1 

1* 

thru 

111111 

1 

63* 

*PABX/PABX  name 

to  be  assigned 

later . 

BUSY  IDLE 

INDICATOR 

CODES 

Code 

Busy/Idle  Indicator 

TABLE  6.3-9.  ACOC  Manual  AUTOVON  Data  Requests 


* Manual  or  Automatic 


REQUEST  TYPES 


Register  Junctor  Call  Processing 
Efficiency  Request 


Pool  Equipment  Status  Request 


Switch  Call  Processing  Efficiency  Request 


Equipment  Status  Request 


General  Data  Request* 


REQUEST  NUMBER 


5 (00000101) 


17  (00010001) 
20  (00010100) 
29  (00011101) 
31  (00011111) 


TABLE  6.3-10.  Possible  Combination  of  Message  and  Data  Types  (Sheet  1 of  2) 


MESSAGE  TYPE 

DATA  TYPES  INCLUDED 

00000001 

(1) 

00000010, 

00010110, 

00010111  or  10000010,  00010110,  00010111 

00000010 

(2) 

00000001, 

00010110, 

00010111  or  10000001,  00010110,  00010111 

00000011 

(3) 

00000001* 

00010110 

00010111 

00000100 

(4) 

00000011* 

, 00010110 

00010111 

00000101 

(5) 

00000011, 

00010110, 

00010111 

00001110 

(14) 

00000110, 

00010110, 

00010111 

00001111 

(15) 

00000111, 

00010110, 

00010111 

00010000 

(16) 

00001000, 

00010110, 

00010111 

00010001 

(17) 

00001100, 

00010001, 

00001101, 

00010010, 

00001110,  00001111,  00010000, 

00010110,  00010111 

00010011 

(19) 

00000100, 

00010110, 

00010111 

00010100 

(20) 

00000100, 

00010110, 

00010111 

00010101 

(21) 

00001001, 

00001010, 

00001011*,  00010110,  00010111 

00010110 

(22) 

00001010, 

00010110, 

00010111 

00010111 

(23) 

00010101, 

00001011* 

00010110,  00010111,  00000010 

00011000 

(24) 

00000001, 

00000010, 

00010110,  00010111 

00011001 

(25) 

00000001, 

00000010, 

00010110,  00010111 

00011010 

(26) 

00001010, 

00001011* 

00010110,  00010111 

00011011 

(27) 

00001011, 

00010110, 

00010111 

00011100 

(28) 

00010011, 

00010110, 

00010111 
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l Table  6.3-10.  Possible  Combination  of  Message  and  Data  Types  (Sheet  2 of  2) 


MESSAGE  TYPE 

DATA  TYPES  INCLUDED 

00011101 

(29) 

00010011,  00010110,  00010111 

00011110 

(30) 

00010100,  00010110,  00010111  and  00010101,  or  00001010 

00011111 

(31) 

Data  Type  Required  by  Request 

00100000 

(32) 

00011000,  00011001 

0D100001 

(33) 

00010100,  00011011,  00010111,  00010111 

♦Multiple  Characters  of  this  Data  Type  are  Possible  in  These  Messages 

l 

1 


r 
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6. 3. 3. 2. 1 AUTOVON  Traffic  Processor 

The  ACOC  AUTOVON  traffic  processor,  shown  in  Figure  6.3-2,  consists  of  17 
subroutines  to  accept  data  messages  from  the  switches.  This  algorithm  will  determine 
the  message  type  and  data  types  within  each  message.  If  a message  contains  incorrect 
data  type(s),  a branch  will  be  made  to  an  error  subroutine.  After  an  incoming  message 
is  determined  to  be  correct,  it  will  be  loaded  into  the  appropriate  section  of  temporary 
storage  to  await  processing  by  the  ACOC  AUTOVON  traffic  data  correlation  processor. 

6.3. 3.  2. 2 AUTOVON  Traffic  Data  Correlation  Processor 

The  ACOC  AUTOVON  traffic  data  correlation  processor,  Figure  6.3-3,  consists 
of  two  sections.  They  are  the  overall  AUTOVON  manager  which  serves  as  an  index 
for  data  from  the  AUTOVON  switches  input  storage  and  the  Processing  and  Display 
section. 

a.  The  Overall  Manager  section  samples  a register  containing  the  message 
types  presently  stored  in  input  storage,  and  directs  the  program  to  the 
subroutine  that  processes  the  data  stored  with  the  appropriate  message  for 
display,  or  display  of  suggested  control  actions.  The  priority  suggested  by 
the  flowchart  is  not  absolute,  and  housekeeping  functions,  such  as  erasing 
the  message  type  after  reading  it  are  eliminated. 

b.  The  Processing  and  Display  sections  is  broken  down  into  thirty  three 
subroutines,  each  associated  with  a particular  input  message  type.  They 
are  individually  explained  below: 

(1)  ^A^  " Terminating  Trunk  Troubles  (Sheet  3).  These  are  terminating 
trunk  troubles  which  were  reported  to  a node  by  an  AUTOVON  Switch 
Level  Module.  As  the  trouble  report  is  read,  the  ACOC  data  base  is 
checked  to  see  if  any  other  troubles  have  been  reported  on  that  trunk. 

If  not,  a trouble  register  with  time  notation  is  started.  If  another 
trouble  has  been  reported,  the  trunk's  trouble  register  is  incremented 
and  the  trouble  time  is  recorded.  A calculation  is  then  made  to  deter- 
mine the  ratio  of  the  number  of  trouble  reports  to  elapsed  time  (time 
computed  in  hours). 
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Figure  6.3-2.  AUTOVON  Traffic  Processor  (Sheet  3 of  8) 
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Figure  6. 3-2.  AUTOVON  Traffic  Processor  (Sheet  4 of  8) 
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Figure  6.3-2.  AUTOVON  Traffic  Processor  (Sheet  5 of  8) 
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Figure  6.3-2.  AUTOVON  Traffic  Processor  (Sheet  6 of  8) 
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Figure  6.3-2.  AUTOVON  Traffic  Processor  (Sheet  7 of  8) 


The  normal  traffic  density  for  the  last  reported  time  is  determined,  simply  by 
asking  if  traffic  at  the  reporting  time  is  normally  heavy.  If  so,  a high  ratio  of 
trouble  per  time  will  be  tolerated,  if  not,  a very  low  ratio  of  troubles  per  time  will 
be  tolerated.  If  either  tolerable  threshold  is  exceeded,  a message  is  generated  to 
the  appropriate  switches  logging  the  circuit  inoperative  and  requiring  the  circuit  to 
be  made  maintenance  busy  at  both  ends. 


(2) 


©■ 


Originating  Trunk  Trouble  (Sheet  4).  These  are  originating 
trunk  troubles  which  are  reported  to  a node  by  an  AUTO  VON  Switch 
Level  Module.  As  the  trouble  report  is  read,  the  ACOC  data  base  is 
checked  to  see  if  any  other  troubles  have  been  reported  on  that  trunk. 

If  not,  a trouble  register  (to  be  shared  by  the  terminating  trouble 
reports)  is  started  for  this  trunk.  If  another  trouble  has  been  reported, 
the  trunk's  trouble  register  is  incremented. 


No  circuit  is  logged  out  of  service  because  of  originating  problems  alone; 
however,  if  a combination  of  originating  and  terminating  troubles  exceeds  the 
threshold  on  Sheet  3,  appropriate  action  is  taken  to  log  the  circuit  out  of  service. 


(3) 


© 


DCX-9  Overload  (Sheet  4).  This  type  message  is  processed  on 


an  originating  trunk  trouble  for  each  circuit  involved. 


(4) 


©- 


Degraded  Register  Junctor  Call  Processing  Efficiency  (Sheet  4). 
These  are  troubles  indicating  a Register  Junctor  is  unable  to  properly 
process  over  90  percent  of  the  calls  attempted.  The  report  has  been 
displayed  at  the  switch  and  is  forwarded  to  the  ACOC. 


Upon  reading  the  data  received  with  this  report,  a determination  of  the  overall 
switch  call  processing  efficiency  of  the  applicable  switch  is  made.  If  the  switch's 
overall  call  processing  efficiency  is  degraded  below  90  percent  (message  type  19), 
the  Register  Junctor  number  along  with  its  percent  call  processing  efficiency  is  also 
displayed.  If  the  switch's  overall  call  processing  efficiency  is  not  degraded  below 
90  percent,  display  of  this  report  is  suppressed. 
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Figure  6.3-3.  AUTOVON  Traffic  Data  Correlation  Processor  (Sheet  3 of  15) 


Figure  6.3-3.  AUTOVON  Traffic  Data  Correlation  Processor  (Sheet  4 of  15) 
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Figure  6.3-3.  AUTOVON  Traffic  Data  Correlation  Processor  (Sheet  5 of  15) 
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Figure  6.3-3.  AUTOVON  Traffic  Data  Correlation  Processor  (Sheet  6 of  15) 
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Figure  6.3-3.  AUTOVON  Traffic  Data  Correlation  Processor  (Sheet  7 of  15) 
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Figure  6.3-3.  AUTOVON  Traffic  Data  Correlation  Processor  (Sheet  8 of  15) 
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Figure  6.3-3.  AUTOVON  Traffic  Data  Correlation  Processor  (Sheet  10  of  15) 
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Figure  6.3-3.  AUTOVON  Traffic  Data  Correlation  Processor  (Sheet  11  of  15) 
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Figure  6.3-3.  AUTOVON  Traffic  Data  Correlation  Processor  (Sheet  12  of  15) 
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Figure  6.3-3.  AUTOVON  Traffic  Data  Correlation  Processor  (Sheet  15  of  15) 
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(5) 


(6) 


(7) 


Manually  Requested  Register  Junctor  Call  Processing 
ciency  (Sheet  4).  In  reply  to  a manual  request,  the  percent  of 
call  processing  efficiency  for  any  Register  Junctor  will  be  supplied 
for  display. 

© - TCMF  Receiver  Overload  on  Degraded  Switch  Call  Processing 
Efficiency  (Sheet  5).  These  are  extreme  overload  conditions  which 
are  reported  only  after  analysis  by  the  reporting  AUTOVON  station 
switch  level  module.  These  reports  are  for  immediate  display. 

©- 


MF  2/6  Transceiver  Overload  on  Degraded  Switch  Call 
Processing  Efficiency  (Sheet  5).  This  is  processed  identically  to 
message  Type  6. 


(8) 


©- 


ATOP  and  Call  Processing  Efficiency  Invalid  (Sheet  5).  This 
is  a direct  result  of  the  Automatic  Overload  Protection  (ATOP)  alarm 
at  the  reporting  switch. 

The  "Call  Processing  Efficiency  Percent  is  Invalid"  display  is  indicated  only 
because  ATOP  blocks  many  calls  from  being  presented  to  the  switch. 

(9)  ^J^-  Line  Load  Control  A and  Call  Processing  Efficiency  Invalid 
(Sheet  5).  This  is  a direct  result  of  Line  Load  Control  A in  effect  at 
the  reporting  switch.  A decision  of  whether  or  not  to  display  the 
"Call  Processing  Efficiency  Percent  Invalid"  statement  is  made  based 
upon  the  previous  presentation  of  another  condition  requiring  that 
statement.  If  one  of  the  other  conditions  is  true,  the  statement  is 
omitted. 

(10)  - Line  Load  Control  B and  Call  Processing  Efficiency  Invalid 
(Sheet  5).  This  is  processed  in  the  same  manner  as  message  Type  9 
(Line  Load  Control  B). 


Q - Line  Load  Control  C and  Call  Processing  Efficiency  Invalid 
(Sheet  5).  This  is  processed  in  the  same  manner  as  message  types 
9 and  10  (Line  Load  Control  A and  B). 

© - All  Registers  Busy  (Sheet  6).  This  is  a direct  report  of  "All 
Register  Junctors  Busy"  from  the  affected  switch.  The  reported  data 
is  read  and  displayed. 

© - ATOP  Switch  Setting  Incorrect  (Sheet  6).  This  is  a report 
based  upon  detection  of  All  Registers  Busy  and  No  ATOP  signal. 
Processing  is  accomplished  at  the  AUTOVON  Station  Switch  Level 
Module.  The  reported  data  is  read  and  displayed. 

Number  and  Percent  of  Register  Junctors  Maintenance  Busy 
(Sheet  10).  This  is  a report  of  the  number  of  register  junctors 


maintenance  busy  when  a threshold  of  Busy  Register  Junctors  is 


reached. 


Upon  reading  the  input  data,  it  is  displayed.  Then  a register  of  heavy  junctor 
traffic  (a  summation  of  message  type  #14  from  the  reporting  switch)  is  sampled. 

If  it  equals  0,  the  report  is  added  and  the  time  of  the  report  is  noted.  If  the  register 
total  is  greater  than  0,  the  total  i8  incremented  by  one  and  the  time  of  the  latest 
report  is  noted.  The  register  is  then  sampled  for  an  indication  of  5 or  more  reports. 
If  so,  and  Line  Load  Control  C is  in  effect,  a test  is  made  of  Line  Load  Control  B. 

If  Line  Load  Control  C is  not  in  effect,  a recommendation  for  its  implementation  is 
displayed.  If  Line  Load  Control  C is  in  effect  and  Line  Load  Control  B is  not  in 
effect,  the  heavy  junctor  traffic  register  is  again  sampled.  If  its  total  is  equal  to  or 
greater  than  8,  implementation  of  Line  Load  Control  B is  recommended.  If  both 
Line  Load  Controls  C and  B are  in  effect,  a test  of  Line  Load  Control  A is  made. 


If  Line  Load  Controls  A,  B and  C are  all  in  effect,  and  the  heavy  junctor  traffic 
register  equals  8 or  more,  a display  recommends  the  ACOC  controller  request  the 
operational  status  of  the  reporting  switch.  If  Line  Load  Controls  B and  C are  in 
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effect,  and  A is  not  in  effect,  the  heavy  junctor  traffic  register  is  sampled.  If  its 
total  is  equal  to  or  greater  than  12,  a display  recommending  implementation  Line 
Load  Control  A is  presented. 

The  thresholds  for  determining  the  need  of  Line  Load  Control  implementation  are 
variable  and  can  be  changed  as  experience  dictates.  A general  housekeeping  routine 
will  clear  the  heavy  junctor  traffic  registers  when  the  last  report  has  been  stored  long 
enough  to  indicate  the  critical  condition  no  longer  exists. 

(15)  © - Number  and  percent  of  TCMF  Receivers  Maintenance  Busy  on 
Threshold  TCMF  Receivers  Busy  (Sheet  6).  This  is  an  indication  of 
impending  heavy  DTMF  type  traffic  when  some  DTMF  Receivers  are 
unavailable.  Processing  involves  reading  and  display  of  data. 

(16)  © - Number  and  Percent  of  MF  2/6  Transceivers  Maintenance  Busy 
on  Threshold  of  MF  2/6  Transceivers  Busy  (Sheet  6).  This  is  an 
indication  of  impending  heavy  MF  2/6  type  traffic  when  some  MF 
Transceivers  are  unavailable.  Processing  involves  reading  and  display 
of  data. 

(17)  © - Pool  Equipment  Status  in  Reply  to  Manual  Request  (Sheet  6). 

This  is  a direct  report  of  all  Register  Junctor,  TCMF  Receiver  and 
MF  2/6  Transceiver  Status  in  reply  to  a manual  request. 


(18)  0 - Assigner  Problem  on  Degraded  Call  Processing  Efficiency 
(Sheet  7).  This  report  is  the  result  of  the  reporting  switch's  call 
processing  efficiency  being  less  than  90  percent  and  an  indication  of  the 
inability  to  assign  TCMF  Receivers  or  MF  2/6  Transceivers.  Proces- 
sing is  limited  to  reading  input  data  and  displaying  it. 
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(19)  Q - Degraded  Call  Processing  Efficiency  (By  Switch)  (Sheet  7). 

This  report  is  the  result  of  the  reporting  switch's  call  processing 
efficiency  being  less  than  90  percent.  Processing  is  limited  to  reading 
input  data  and  displaying  it. 

Q- Manually  Requested  Switch  Call  Processing  Efficiency  (Sheet  7). 
This  is  a report  of  a switch's  call  processing  efficiency  in  reply  to  a 
manual  request.  Processing  is  limited  to  reading  input  data  and  dis- 
playing it.  Provisions  for  displaying  previously  recently  stored  call 
processing  efficiency  data  while  waiting  for  an  update  are  also  made 
(Connector  VI). 


(20) 


(21)  [W j - Excessive  Number  of  Calls  Being  Alternate  Routed  from 

Reporting  Switch  to  a Connecting  Switch  for NNX/NYX  Code(s). 

(Sheet  8).  This  is  a report  of  a precedence  call  being  blocked  from  an 
alternate  route  because  of  insufficient  precedence  level  when  over  60 
percent  of  the  calls  are  moving  in  the  direction  of  the  terminating 

switch,  and  over * (Threshold  Percent)  of  these  calls  not  on  their 

primary  trunk  group.  The  input  data  of  message  type,  reporting 
switch  identity,  and  connecting  switch  identity  are  used  to  determine  the 
Route(s)  on  which  the  call  was  blocked,  and  the  switch  in  which  the 
blockage  occurred.  During  the  processing.  Busy  /Idle  indicator  sum- 
maries are  requested  for  affected  trunk  groups  in  the  appropriate 
switch(es)  and  are  used  to  determine  where  blockage  occurred.  The 
result  of  the  processing  will  be  a determination  if  the  blockage  was 
genuine,  and  if  so,  cancellation  of  the  affected  alternate  route  will  be 
recommended. 


Threshold  to  be  determined. 


I 


(22)  Q- ATB  and  Receiving  an  Excessive  Number  of  Calls  from 

Connecting  Switch  (Sheet  9).  This  is  a report  of  Precedence  Blocked 
calls  incoming  on  trunks  from  a particular  switch  when  over  60  percent 
of  trunks  from  that  switch  are  originating  calls  into  the  reporting  switch, 
all  trunks  on  the  incoming  trunk  group  are  busy,  and  a precedence  call 
is  blocked  attempting  to  find  a route  out  of  the  reporting  switch. 

Processing  is  limited  to  reading  input  data  and  displaying  it. 


(23)  Q-  Immediate  Precedence  Blockage  Terminating  to  a PBX  (Sheet  9). 
This  is  a report  of  Immediate  or  Higher  Precedence  being  blocked  in  an 
attempt  to  terminate  to  a PBX.  Upon  reading  the  input  data,  a deter- 
mination of  whether  the  PBX  is  dual  homed  or  not  is  made.  If  the  switch 
is  dual  homed,  a search  for  a similar  trouble  report  from  the  second 
switch  is  made.  If  so,  the  Immediate  Precedence  Blockage  to  (PBX 
Name)  message  is  displayed,  followed  by  a message  to  the  switch  to 
make  defective  trunks  maintenance  busy.  If  the  PBX  is  dual  homed  and 
no  similar  trouble  report  is  present  from  the  second  switch,  the 

message  "Immediate  Precedence  Blockage  to (PBX  Identity), 

Suggest  Codes  routing  to (PBX  Identity)  via (Switch  Identity)  be 

isolated. 

(24)  © - Immediate  Precedence  Blockage  - Tandem  Traffic  (Sheet  11). 
This  is  a report  of  Immediate  or  Higher  Precedence  being  blocked  in 
an  attempt  to  tandem  through  the  reporting  switch.  This  report  will 
originate  at  switches  utilizing  spill  control  (normally  gateways).  Upon 
reading  the  input  data,  the  originating  and  terminating  connecting 
switches  are  determined,  and  available  data  is  displayed.  A request 
for  a status  update  on  the  normal  terminating  trunk  group  is  forwarded 
to  the  reporting  Switch  Level  Module,  and  the  display  is  updated  upon 
receipt  of  the  status  information.  If  the  trunk  group  reports  any  status 
lower  than  Immediate  precedence,  the  display  is  flagged  indicating 
trunk  trouble. 


(25)  0 Immediate  Precedence  Blockage  - Originating  (Sheets  12  and  13). 
This  is  a report  of  Immediate  or  Higher  Precedence  blockage  of  a call 
originated  at  the  reporting  switch. 

Upon  reading  the  input  data,  a test  is  made  to  determine  if  a message  type  26  is 
available  from  the  reporting  switch  on  the  switch  (trunk  group(s))  on  which  the 
Reported  NNX/NYX  codes  are  primarily  routed.  If  so,  the  status  of  the  trunks  on 
this  route  is  requested  from  the  reporting  switch.  The  originating  Immediate 
Blocking  Message  with  appropriate  data  is  displayed,  and  after  receipt  of  the  trunk 
status  summary,  is  updated.  If  any  status  was  lower  than  Immediate  precedence, 
the  appropriate  trunk  group  display  is  flagged  with  a trouble  indicator. 

If  no  applicable  message  type  26  is  available,  a test  is  made  to  determine  if 
alternate  routes  for  the  reported  NNX/NYX  code(s)  have  been  previously  cancelled. 

If  they  have,  the  primary  routing  for  the  NNX/NYX  code(s)  reported  is  determined 
from  the  area  routing  tables,  and  each  switch  in  the  route  is  tested  for  blockage,  and 
the  Immediate  Precedence  blockage  reporting  switch  and  the  switch  where  blockage 
is  occurring  is  displayed. 

If  alternate  routes  for  the  reported  NNX/NYX  code(s)  have  not  been  previously 
cancelled,  all  possible  routes  for  the  NNX/NYX  code(s)  reported  are  reconstructed, 
and  the  first  six  are  tested  for  blockage  conditions  at  an  intermediate  switch.  A 
display  is  presented  showing  the  Immediate  precedence  blockage,  reporting  switch 
and  the  switch  where  blockage  is  occurring. 

(26)  (ac)  - Overload  in  1st  Tandem  Switch  (Sheet  12).  This  is  a report 
indicating  the  first  switch  in  Tandem  in  unable  to  route  a call,  and 
the  originating  switch  alternate  route  counter  has  reached  a count  of  5 
because  of  the  second  switch's  inability  to  route  the  call.  Processing 
is  limited  to  storage  of  the  input  data  for  processing  upon  receipt  of  a 
message  type  25  input. 
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(27)  © - ATPC  Plan  #2  Announcement  Accessed  (Sheet  14).  This  is  a 
report  that  the  Isolated  code  announcement  at  the  reporting  switch  has 
been  selected  as  the  terminator  for  a call. 

Upon  receipt  of  the  data  accompanying  this  message,  all  ATPC  codes  stored  by 
the  ACOC  Controller  for  the  reporting  switch  are  read.  A comparison  is  then  made 
to  determine  if  the  ATPC  code  accessed  equates  to  one  stored,  thus  is  legitimate.  If 
the  ATPC  code  access  is  legitimate,  a test  is  made  of  general  network  conditions  in 
the  route  of  the  NNX/NYX  codes  causing  the  ATPC  access.  If  no  degradation  is 
reported,  the  reporting  switch  ID  is  displayed  along  with  a message  questioning  the 
need  for  the  ATPC  Plan. 

If  the  NNX  code  for  the  ATPC  Plan  accessed  does  not  compare  with  one  stored 
by  the  controller,  it  is  assumed  to  be  erroneously  stored,  and  a message  indicating 

the  reporting  switch,  ATPC  Plan  #2  in  effect  for NNX/NYX  code(s)  at 

Time,  and  a reminder  to  update  or  remove  the  plan  in  effect. 

(28)  © - Equipment  Status  on  Degraded  Call  Processing  (Sheet  14).  This 
is  a report  of  Equipment  Out  of  Service  conditions,  comparator  in 
manual  mode,  and  Line  Load  Control,  when  the  reporting  switch's  call 
processing  efficiency  is  less  than  90  percent. 

Processing  is  limited  to  display  of  input  data. 


©- 


Manually  Requested  Equipment  Status  (Sheet  14).  This  is  a 


reply  containing  the  in  or  out  of  service  status  of  all  common  control 
and  marker  equipment. 

Processing  is  limited  to  display  of  input  data. 


(30)  (AGJ-  ATB  (All  Trunks  Busy)  (Sheet  15).  This  is  a report  of  ATB  on 
any  Inter-Swtich  or  PBX  Trunk  group.  Upon  receipt  of  the  input  data, 
a test  is  made  to  determine  if  the  condition  has  existed  for  5 minutes  or 
longer.  Nothing  is  done  if  it  has  not. 
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If  the  condition  has  persisted  for  5 minutes,  the  connecting  switch  is  determined 
on  Inter-Switch  trunk  groups,  and  a test  is  made  to  determine  if  the  connecting  switch 
also  indicates  ATB  on  the  trunk  group  to  the  reporting  switch.  If  so,  "Continuous  ATB 
on  trunks  between  (Reporting  Switch  ID)  and  (Connecting  Switch  ID)  since  (Starting 
Time).  If  ATB  is  not  true  on  the  connecting  switch's  trunk  group,  a display  indicating 
ATB  trouble  between  (switch  ID's)  is  prescribed. 

(31)  © - General  Data  Input  (Sheet  15).  This  is  a reply  to  any  manually 
requested  data.  Processing  is  limited  to  reading  and  displaying  input 
data. 

(32)  © - Busy/Idle  Status  Summary  (Sheet  15).  This  is  a reply  to  auto- 
matic requests  made  by  other  subroutines.  Processing  is  limited  to 
reading  and  storing  data  for  use  by  the  requesting  subroutines. 

(33)  ^AK^-  Busy/Idle  Indicator  (Sheet  15).  This  is  a reply  to  automatic 
requests  made  by  other  subroutines.  Processing  is  limited  to  reading 
and  storing  data  for  use  by  the  requesting  subroutines. 


6.3. 3. 2. 3 AUTOVON  Traffic  Display  Processor 

This  algorithm,  shown  in  Figure  6.3-4,  processes  inputs  from  the  ACOC 
controller.  Sheet  1 illustrates  the  response  to  requests  for  more  information.  Five 
types  of  requests  are  possible: 

1.  Request  '*5  - Register  Junctor  Call  Processing  efficiency 

2.  Request  #17  - Pool  Equipment  Status 

3.  Request  #20  - Switch  Call  Processing  Efficiency 

4.  Request  #29  - Equipment  Status 

5.  Request  #31  - General  Data 

Sheet  2 shows  the  routine  for  storing  and  displaying  the  control  actions  that 
have  been  implemented  by  the  controller.  A list  of  codes  is  included  as  Table 
6.3-11.  Upon  reading  and  storage  of  the  manual  input  action,  those  codes  relating 
to  Line  Load  Control  are  separated  from  the  remainder  and  a display  indicating  that  the 
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switch  action  has  not  been  taken  is  presented  until  a report  indicating  the  action  in 
effect  has  been  received  from  the  appropriate  switch.  Regardless  of  the  action  data 
type,  a display  of  manual  control  actions  in  effect  is  presented  every  five  minutes  for 
thirty  seconds. 

The  remove  section  of  this  algorithm  deletes  any  manually  input  action  upon 
demand. 

6. 3.  3.  3 Optional  Display 

A comprehensive  near  real  time  display  of  the  switching  network  situation 
including  traffic  overloads,  manually  input  alternate  routing  decisions,  i.e.,  ATPC 
Plans,  Red  Decks,  or  Directionalization  of  trunks,  could  be  provided  by  use  of  a 
large  situation  display  board  utilizing  a geographically  oriented  communications 
area  layout  and  alpha-numeric/graphic  computer  controlled  display.  The  improved 
system  visability  provided  by  this  type  of  display  is  necessary  to  supplement  the 
smaller  less  comprehensive  CRT  display.  The  benefits  derived  from  the  improved 
system  visability  make  its  inclusion  at  the  ACOC  worth  consideration.  Figures 
6.3-5  and  6.3-6  depict  a concept  of  this  type  of  display  for  Europe. 
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Figure  6.3-4.  AUTOVON  Traffic  Display  Processor  (Sheet  1 of  2) 
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Figure  6.3-4.  AUTOVON  Traffic  Display  Processor  (Sheet  2 of  2) 


Table  6.3-11.  Manual  Input  Actions  Codes 


00000001 

(1) 

ATPC  Plan  # 1 NNX/NYX  Codes 

Switch  Code(s) 

00000010 

(2) 

ATPC  Plan  # 2 NNX/NYX  Codes 

Switch  Code(s) 

00000011 

(3) 

Line  Load  Control  C 

00000100 

(4) 

Line  Load  Control  B 

00000101 

(5) 

Line  Load  Control  A 

00000110 

(6) 

Directionalization (Trunk  Group (s) 

) 

00000111 

(7) 

Log  Switch  Out  of  Operation 

00001000 

(8) 

Red  Deck  # 

00010001 

Remove  ATPC  Plan  # 1 NNX/NYX  Codes 

Switch  Code(s) 

00010010 

00010011 

00010100 

00010101 

Remove  ATPC  Plan  # 2 NNX/NYX  Codes 

Remove  Line  Load  Control  C 

Remove  Line  Load  Control  B 

Remove  Line  Load  Control  A 

Switch  Code(s) 

00010110 

00010111 

00011000 

Remove  Directionalization (Trunk  Group (s)  ) 

Log  Switch  In  Operation 

Green  Deck  # 
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Figure  6.3-5.  ACOC  AUTOVON  Situation  Display 
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7.1  GENERAL 

Budgeting  costing  for  the  unified  control  system  is  presented  in  this  section. 
Hardware,  special  interface,  engineering,  software,  and  documentation  costs 
are  addressed  specifically  for  the  European  DCS. 

7.2  HARDWARE  COSTS  FOR  UNIFIED  CONTROL 

The  hardware  costs  presented  in  this  paragraph  include  the  costs  of  significant 
off-the-shelf  equipment  items  and  the  specially  built  AUTO  VON  switch  interface. 

The  computer  hardware  prices  are  provided  for  currently  available  off-the-shelf 
hardware  which  satisfies  the  minimum  requirements  set  forth  in  earlier  sections 
of  this  report.  Tables  7.2-1  through  7.2-3  summarize  hardware  costs  for  single 
installations  of  the  ACOC,  Sector,  and  Node  level  elements  respectively.  Table 
7.  2-4  presents  station  level  hardware  costs  including  terminal  and  switch  interface 
equipment  for  the  entire  European  DCS.  Table  7.2  -5  shows  the  estimated  hardware 
costs  for  Europe  assuming  that  the  unified  control  systems  consists  of  one  ACOC, 
four  Sector,  and  sixteen  Node  installations. 

From  this  table,  the  European  hardware  cost  is  on  the  order  of  $1. 6M. 

This  cost  assumes  that  communications  facilities  providing  interfaces  among  the 
various  unified  control  elements  are  supplied  out  of  the  current  DCS. 

7.3  SOFTWARE  COSTS  FOR  UNIFIED  CONTROL 

The  software  implementation  and  documentation  costs  for  unified  control 
are  presented  in  this  paragraph.  These  costs  are  derived  from  the  results  of 
the  sizing  analysis  presented  in  earlier  sections  of  this  report,  and  estimations 
of  software  documentation  requirements  to  satisfy  military  documentation  standards. 

Table  7.3-1  summarizes  the  overall  software  estimates  for  unified  control. 

The  table  lists  each  unique  program  in  the  system,  the  estimated  size  of  the 
program  in  lines  of  code,  and  shows  the  major  unified  control  elements  where  it 
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Table  7.2-1.  Budgetary  Hardware  Pricing  for  the  ACOC 

*1 

1 3 


Equipment 

Quantity 

Unit  Cost 

Extended  Cost 

CPU  with  128K  bytes 

1 

20,000 

20,000 

1 OM  byte  moving  head 
disk  and  controller 

1 

12,000 

12,000 

Magnetic  Tape  Drive 
and  Controller 

1 

10,000 

10,000 

CRT  Terminal  with 
Local  Print  and 
Controller 

4 

5,000 

20,000 

Synchronous  Channel 

6 

1,200 

7,200 

Total 

$69,200 

Table  7.2-2.  Budgetary  Hardware  Pricing  for  the  Sector 
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Equipment 

Quantity 

Unit  Cost 

Extended  Cost 

CPU  with  128K 
bytes 

1 

20,000 

20,  000 

10M  byte  moving 
Head  Disk  and 
Controller 

1 

12,000 

12,000 

Magnetic  Tape 
Drive  and 
Controller 

1 

10, 000 

10, 000 

CRT  Terminal 
with  Local  Print 
and  Controller 

2 

5,000 

10,000 

Synchronous 

Channel 

8 

1,200 

9,  600 

Total 


$61,600 


Table  7.2-3.  Budgetary  Processor/Peripheral  Hardware  Pricing 

for  the  Node 


Equipment 

Quantity 

Unit  Cost 

Extended  Cost 

CPU  with  128K  bytes 

1 

20,000 

20,000 

5M  byte  Moving  Head 
Disk 

1 

10, 000 

10,000 

Magnetic  Tape  Drive 
and  Controller 

1 

10,000 

10,000 

Node  Controller 

CRT  Terminal 
with  Local  Print 

1 

5,000 

5,000 

Synchronous 

Channel  (ACOC  + 
ATEC) 

2* 

1,200 

2,400 

Total 

47,400 

♦Assume  each  Node  interface  with  ATEC 
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Table  7.2-4.  Budgetary  Station  Level  Hardware  Pricing 


Equipment 

Station  Controller 
CRT  Terminals 

Station  Controller 
CRT  Terminals 
with  Local  Print 

AUTODIN  Report 
Processor  Interface 

AUTO  VON  Switch 

Interface 

TOTAL 


Quantity  Unit  Cost 


3,000 


5,000 


14,200 


Extended  Cost 


171,000 


220,000 


1,500 


142,000 


Requirement  for  local  print  capabilities  based  on  the  number  of  circuits  in 
a particular  station 

"Trunk  Scanner  Interface  Buffer  - 4500 

Level  Converter  and  Multiplexer  - 6600 
Racks,  cables,  PCB  files  - 2500 

Multiplexer  Dual  Power  Supply  - 600 

Total  14,200 


fi 


4 
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Table  7.2-5.  Summary  of  Unified  Control  Hardware 
Pricing  for  Europe. 


— f 

f 

i 

1 

I 

1 


TOTAL 


$1,608,500 


Table  7.3-1.  Summary  of  Overall  Unified  Control  Software  Estimates 

(Sheet  1 of  5) 


PROGRAM  NAME 

# INST 
HOL 

ACOC 

SECTOR 

NOE 

ACOC  Supervisor 

300 

X 

Sector  Supervisor 

300 

X 

Node  Supervisor 

300 

X 

Sector  I/O  Driver 

100 

X 

X 

X 

ACOC  I/O  Driver 

100 

X 

X 

Node  I/O  Driver 

100 

X 

CRT  I/O  Driver 

200 

X 

X 

X 

STATS  I/O  Driver 

75 

X 

ATEC  I/O  Driver 

100 

X 

VON  Module  I/O  Driver 

100 

X 

AUTODIN  I/O  Driver 

100 

X 

ACOC  Message  Processor 

50 

X 

ACOC  Message  Processor  (S) 

50 

X 

Sector  Message  Processor 

50 

X 

Sector  Message  Processor  (S) 

50 

X 

Sector  Message  Processor  (N) 

50 

X 

Node  Message  Processor 

50 

X 

ACOC  Controller  Message  Processor 

50 

X 

Sector  Controller  Message  Processor 

50 

X 

Nodal  Controller  Message  Processor 

50 

X 

Station  Message  Processor 

50 

X 

STATS  Message  Processor 

50 

X 

SATCOM  Message  Processor 

50 

X 

ATEC  Message  Processor 

50 

X 

AUTOVON  Message  Processor 

50 

X 

AUTODIN  Message  Processor 

50 

X 

Journal  Inspection  Processor 

275 

X 

X 

Journal  Inspection  Processor  (N) 

75 

X 

Fault  Notification  Broadcast  Processor 

250 

X 

Fault  Notification  Broadcast  Processor  (S) 

300 

X 

Fault  Notification  Broadcast  Processor  (N) 

275 

X 

Fault  Update  Broadcast  Processor 

250 

X 

Fault  Update  Broadcast  Processor  (S) 

300 

X 

Fault  Update  Broadcast  Processor  (N) 

275 

X 

Fault  Closure  Broadcast  Processor 

250 

X 

Fault  Closure  Broadcast  Processor  (S) 

300 

X 

Fault  Closure  Broadcast  Processor  (N) 

275 

X 

Broadcast  Message  Generator 

100 

X 

X 

X 

Fault  Summary  Processor 

150 

X 

X 

Node  Fault  Summary  Processor 

200 

X 

Table  7.3-1.  Summary  of  Overall  Unified  Control  Software  Estimates 
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PROGRAM  NAME 

# INST 
HOL 

ACOC 

SECTOR 

NODE 

Fault  Record  Retrieve 

50 

X 

X 

Fault  Record  Retrieve  (N) 

100 

X 

ACOC  Fault  Retrieval  Processor 

75 

X 

ACOC  Fault  Destination  Processor 

50 

X 

Sector  Fault  Retrieval  Processor 

75 

X 

Sector  Fault  Destination  Processor 

50 

X 

Sector  Fault  Update 

100 

X 

Sector  Traffic  Fault  Processor 

75 

X 

Node  Fault  Retrieval  Processor 

75 

X 

Node  Fault  Destination  Processor 

75 

X 

Node  Fault  Input  Processor 

400 

X 

Node  Fault  Update 

150 

X 

Fault  Responsibility  Accept 

75 

X 

Station  Fault  Accept 

100 

X 

Station  Fault  Update 

150 

X 

Station  Fault  Close 

200 

X 

Connectivity  Display  Processor 

200 

X 

X 

Connectivity  Display  Processor  (N) 

200 

X 

Connectivity  Modification  Processor 

500 

X 

X 

X 

Connectivity  Mod  Request  Processor  (S) 

50 

X 

Network  Modification  Processor 

75 

X 

Configuration  Update  Processor 

50 

X 

Reroute  Directive  Processor 

100 

X 

X 

Reroute  Authorization  Processor 

50 

X 

Reroute  Confirmation  Processor 

200 

X 

Reroute  Confirmation  Processor  (S) 

200 

X 

Reroute  Confirmation  Processor  (N) 

200 

X 

Reroute  Request  Processor 

50 

X 

Node  Reroute  Destination  Processor 

50 

X 

Media  Status  Retrieval  Processor 

250 

X 

X 

X 

PMP/QA  Measurement  Processor 

50 

X 

Sector  PMP/QA  Measurement  Processor 

50 

X 

PMP/QA  Request  Processor 

50 

X 

X 

PMP/QA  Gather 

50 

X 

PMP/QA  Data  Accept 

75 

X 

PMP/QA  Destination  Processor 

50 

X 

Measurement  Destination  Processor 

50 

X 

Manual  Measurement  Request  Proc  (S) 

50 

X 

Manual  Measurement  Request  Proc  (N) 

50 

X 

Manual  Measurement  Accept 

75 

X 

Table  7.3-1.  Summary  of  Overall  Unified  Control  Software  Estimates 

(Sheet  3 of  5) 


PROGRAM  NAME 

# INST 

HOL 

ACOC 

SECTOR 

NODE 

Manual  Measurement  Destination  Proc  (N) 

50 

X 

Sector  Manual  Measurement  Processor 

75 

X 

Automated  Measurement  Request  Proc  (S) 

50 

X 

Sector  Automated  Measurement  Proc 

75 

X 

Free  Text  Message  Processor 

50 

X 

X 

X 

SATCOM  Fault  Accept 

75 

X 

SATCOM  Fault  Update 

100 

X 

SATCOM  Fault  Close 

100 

X 

Traffic  Control  Processor 

100 

X 

STATS  Summary  Processor 

50 

X 

AUTOVON  Traffic  Processor 

300 

X 

AUTOVON  Station  Equipment  Processor 

50 

X 

AUTODIN  Station  Equipment  Processor 

50 

X 

AUTOSEVOCOM  Station  Equip  Processor 

50 

X 

HA Z CON  Processor 

75 

X 

HA Z CON  Accept 

100 

X 

Station  Initialize 

50 

xv 

Link  Connectivity  Retrieve 

50 

X 

X 

X 

VFCT  Trunk  Connectivity  Retrieve 

200 

X 

X 

X 

Trunk  Connectivity  Retrieve 

100 

x 

X 

X 

CCSD  Connectivity  Retrieve 

200 

X 

X 

X 

Link  Connectivity  Update 

100 

X 

X 

X 

VFCT  Trunk  Connectivity  Update 

400 

X 

X 

X 

Trunk  Connectivity  Update 

200 

X 

X 

X 

CCSD  Connectivity  Update 

400 

X 

X 

X 

Station  Equipment  Update 

100 

X 

X 

X 

Switch  Equipment  Update 

100 

X 

Precedence  Determine 

400 

X 

Precedence  Determine  (S) 

400 

X 

Precedence  Processor 

400 

X 

Destination  Processor 

50 

X 

X 

X 

Terminating  Sector  Determine 

50 

X 

X 

Destination  Sector  Determine 

150 

X 

X 

Terminating  Node  Determine 

50 

X 

X 

Destination  Node  Determine 

150 

X 

X 

Terminating  Station  Determine 

50 

X 

Destination  Station  Determine 

150 

X 

Fault  File  Manager 

150 

X 

X 

X 

Fault  Summary  Generator 

50 

X 

X 

X 

Associated  Fault  Purge 

100 

X 

X 

Table  7.3-1.  Summary  of  Overall  Unified  Control  Software  Estimates 
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# INST 


PROGRAM  NAME 


Detailed  Fault  Generator 
Control  Action  Log  Manager 
Journal  Output  Manager 
Connectivity  Mod  Syntex  Check 
CRT  Output  Buffer  Manager 
CRT  Output  Buffer  Manager  (S) 

DIN  Traffic  Threshold  Check 
VON  Traffic  Data  Correlation  Processor 
AUTOVON  Traffic  Display  Processor 
AUTODIN  Traffic  Display  Processor 
AUTOVON  Switch  Equip  Status  Retrieve 
AUTODIN  Switch  Equip  Status  Retrieve 
AUTOSEVOCOM  Switch  Equip  Status 
Retrieve 

ATEC  Query  Processor 
AUTODIN  Station  Initialize 
AUTOVON  Station  Initialize 
AUTOSEVOCOM  Station  Initialize 
TCF  Station  Initialize 
Earth  Terminal  Complex  Station  Initialize 
Station  File  Manager 
Link  File  Manager 
Trunk  File  Manager 
VFCT  Trunk  Manager 
CCSD  File  Manager 
Journal  Input  Manager 
Journal  Display  Formatter 
Communications  Message  Formatter 
Display  File  Manager 
Display  Generator 
Display  Generator  (S) 

Display  Generator  (N) 

Fault  File  Search 

Fault  File  Linkage  Modification 

Fault  Filter 

Related  Fault  Record  Manager 
AUTOVON  Detail  File  Manager 
AUTODIN  Detail  File  Manager 
AUTOSEVOCOM  Detail  File  Manager 
Precedence  Determine  (N) 
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3L 

ACOC 

SECTOR 

NODE 

75 

X 

150 

X 

50 

X 

X 

X 

100 

X 

200 

X 

100 

X 

X 

50 

X 

750 

X 

300 

X 

50 

X 

50 

X 

50 

X 

50 

X 

150 

X 

50 

X 

50 

X 

50 

X 

50 

X 

50 

X 

175 

X 

X 

X 

175 

X 

X 

X 

150 

X 

X 

X 

175 

X 

X 

X 

200 

X 

X 

X 

175 

X 

X 

X 

100 

X 

X 

X 

150 

X 

X 

X 

50 

X 

X 

X 

50 

X 

50 

X 

50 

X 

75 

X 

X 

X 

150 

X 

X 

X 

50 

X 

X 

X 

50 

X 

X 

X 

100 

X 

100 

X 

100 

X 

100 

X 

A A •-  Kr.y * 


I 

I 


Table  7.3-1.  Summary  of  Overall  Unified  Control  Software  Estimates 
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PROGRAM  NAME 

# INST 

IlOL 

ACOC 

SECTOR 

NODE 

ATEC  Message  Generator 

50 

X 

ATEC  Fault  Record  Generator 

75 

X 

VON  Fault  Record  Generator 

75 

X 

DIN  Fault  Record  Generator 

75 

X 

AUTOVON  Trunk  Translator 

50 

X 

ACOC  Controller  Decode/Validation 

100 

X 

SATCOM  Controller  Decode/Validation 

75 

X 

Sector  Controller  Decode/Validation 

100 

X 

Node  Controller  Decode/Validation 

75 

X 

Station  Operator  Decode/Validation 

100 

X 

Message  Type  Decode 

175 

X 

X 

X 

AUTOVON  Message  Decode 

50 

X 

AUTODIN  Message  Decode 

50 

X 

I/O  Error  Processor 

150 

X 

X 

X 

Journal  Block  Formatter 

150 

X 

X 

X 

Communications  Buffer  Manager 

100 

X 

X 

X 

CRT  Buffer  Manager 

75 

X 

X 

X 

STATS  Buffer  Manager 

50 

X 

Station  Output  Buffer  Manager 

■a 

X 

AUTODIN  Buffer  Manager 

B£S 

X 

AUTOVON  Buffer  Manager 

100 

X 

ATEC  Buffer  Manager 

100 

X 

Communications  Message  File  Manager 

50 

X 

X 

X 

FIND 

500 

X 

X 

X 

GET 

500 

X 

X 

X 

CREATE 

500 

X 

X 

X 

DELETE 

500 

X 

X 

X 

MODIFY 

500 

X 

X 

X 

VON  Module 

1625 

TOTAL 

26,625 

X X X X X 


is  used.  This  table  only  addresses  installed  code  which  is  estimated  to  consist  of 
26,625  unique  lines. 

Table  7.3-2  presents  the  software  labor  estimates  for  the  system.  The  table 
includes  labor  estimates  for  design,  coding,  and  debugging  of  the  software,  re- 
quirements and  product  specifications,  test  plans,  and  user's  manuals.  The  design, 
code,  and  debug  estimate  is  based  on  26,625  line  of  operational  software  and  3,000 
lines  of  auxiliary  data  base  preparation  software.  The  estimated  labor  for  soft- 
ware activities  is  4803  man  days  or  about  20.5  man  years. 
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Table  7.  3-2.  Bugetary  Software  Development  and  Documentation 
Cost  Estimates  for  Unified  Control 


4 


I 


I 


4» 


l 


I 

I 


I I 

f 

I 
I 
I 


TASK 

NO. 

MAN  DAYS 

RATIONALE 

Design,  Code,  Debug 

3703 

♦ 

29,625  lines  at  8 lines/day 

Requirements  Specific- 
ations (B5) 

250 

500  pages  at  2 pages /day 

Product  Specifications  (C5) 

450 

900  pages  at  2 pages /day 

Test  Plans 

250 

500  pages  at  2 pages/day 

User's  Manuals 

150 

300  pages  at  2 pages/day 

TOTAL 

4803 

* Installed  Software  - 26,625  lines 
6 Major  File  Generators  - 3,000  lines 
@ 500  lines  each 


TOTAL  - 29,625  lines 
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APPENDIX  A 


This  Appendix  contains  the  detailed  descriptions  of  the  algorithms  used  in 

\ 

the  loading  analysis.  Each  algorithm  is  flowcharted  and  analyzed  for  the  number  of 
assembly  level  instructions  executed,  disk  accesses  performed,  and  characters 
displayed  in  performing  a single  execution  of  the  algorithm. 


A-l 


ALGORITHM  - A1 


DESCRIPTION  - ACOC  - Receipt  of  Fault  Notification  Broadcast  from  Sectors 


Processing 


Input 

Handling 


Message 

Parsing 


Severity 

Check 


Media 

Record 

Retrieval 


Fault  ID 
Update 


Reroute 

Flag 

Update 


No.  N 
No.  Disk  Cl 
Inst.  Access  Displayed 


230  2 


Rationale 


30  byte  message  § 2 inSt/byte  for  error 
processing. 

25  instructions/buffer  switch 

10  inst  to  decode  message 

1 disk  access  for  overlay  @ 50  inst/access 


25  data  bytes  @ 4 inst/byte 


5 severities  @ 5 inst/check 


2 disk  accesses  - 1 directory;  1 record 
50  inst/access  - 100  inst 
5 directories  @ 10  inst/dir  address  compute 
Hash  - 8 character  field  § 10/char 


3 words  § 10  inst/word 


1 word  i m 10  inst/word 


jpipttfii 


No. 

Inst 


No.  No. 

Disk  Char 
Access  Displayed 


Rationale 


10 


1 word  @ 10  Inst 


10 


1 word  @ 10  inst 


60 


10  inst  for  linkage 
50  inst  for  disk  access 


50 


2 theaters  @ 25  inst/check 


(10  inst  to  affix  destination 
10  inst  to  affix  source 
50  inst  to  move 


120 


12  fields  @ 10  Inst/field 


A -3 


ALGORITHM  - A2 

DESCRIPTION  - ACOC  - Fault  Notification  from  Another  ACOC 


Processing 


No.  N' 
No.  Disk  Cl 
Inst.  Access  D 


Input 

Handling 


Message 

Parsing 


Severity 

Check 


Media  Record 
Retrieval 


Fault  ID 
Update 


30  byte  message  @ 2 inst/byte  for  error  processing 
25  instructions/buffer  switch 
10  inst  to  decode  message 
1 disk  access  for  overlay  § 50  inst/ access 


25  data  bytes  @ 4 inst/byte 


5 severities  @ 5 inst 


2 disk  accesses  - 1 directory;  1 record  @ 

50  inst/access 

5 directories  § 10  inst  for  address  computation 
8 character  field  @ 10  inst/char  for  Hash 


3 words  @ 10  inst 


Reroute  Flag 
Update 


1 word  (8  10  inst 


bkt. 

4 

* 

ALGORITHM  - A2  (Continued) 


DESCRIPTION  - ACOC  - Fault  Notification  from  Another  ACOC 


No.  No. 

No.  Disk  Char 

Proceasing  Inst.  Access  Displayed  I 


Isolation 

Indicator 

Update 


DOD 

Update 


Restore  Media 
Record 


Sector 

Notification 

Check 


Notification 

Message 

Forwarding 


Controller 
Status  Summary 


Update 


• • ■ 


Rationale 


1 word  @ 10  inst 


1 word  & 10  inst 


10  inst  for  linkage 
50  inst/disk  access 


6 data  base  accesses  @ 2 disk  accesses  each  @ 50  inst 

5 trunks/CCSD  @ 50  inst 

6 stations/trunk  & 50  inst 

4 sectors  @ 50  inst  for  destination  check 


(10  inst  to 
10  inst  to 
50  inst  to 


affix  destination 
affix  source 


12  fields  @ 10  inst 


A-6 


ALGORITHM  - A4 

DESCRIPTION  - ACOC  - Request  to  Enter  a Fault  Report  (SATCOM) 


Processing 


Input 

Handling 


Parsing 


Generate 

Fault 

Record 


Media  Type 
Check 


Media 

Record 

Retrieval 


Y Not 

Previously 

Reported 


No. 

No. 

No. 

Disk 

Char 

Inst. 

Access 

Displayed 

Rationale 


45  character  Message  @ 15  inst/char  for 
validation 

25  inst/buffer  switch 
1 disk  access  for  overlay  § 50  inst 


8 fields  @ 10  inst 


20  fields  @ 10  inst 


4 levels  @ 25  inst 


1 media  file  access  @ 2 disk  accesses  @ 50  inst 
8 character  field  @ 10  inst/char  for  hash 
50  inst  for  directory  arbitration 


25  inst  to  determine  status 
3 inst  for  conditional  test 


.ft'#*: 


ALGORITHM  - A*  (Continued)  f 

DESCRIPTION  - ACOC  - Request  to  Enter  a Fault  Report  (SATCOM) 


No.  No. 

No.  Disk  Char 
Inst.  Access  Displayed 


Add  New  Fault 
to  File 


ALGORITHM  - A4  (Continued) 

DESCRIPTION  - ACOC  - Request  to  Enter  a Fsult  Report  (SATCOM) 


No.  No. 

No.  Disk  Char 

Processing  Inst.  Access  Displayed 


3 words  @ 10  inst/word 


Reroute  Flag 
Update 


Isolation 

Indication 

Update 


1 word  @ 10  Inst 


1 word  @ 10  inst 


Do  D Update 


1 word  @ 10  inst 


Restore 


Record 


ACOC 

Notification 

Check 


10  Inst  for  linkage 
50  inst  for  disk 


2 theaters  @ 25  inst 


3 


ALGORITHM  - A5 


DESCRIPTION  - Retrieve  and  Display  CCSD  Connectivity  to  ACOC  Controller 


Processing 


Parsing 


Connectivity 

Overlay 

Retrieval 


No. 

Disk 

Access 


1 

i 1 

Input 

Handling 

1 ! r 

r 

Request 

4 

* 

mm 

Retrieval  Type 
Check 

[ 

Retrieve 

r 

11 

CCSD  Record 

Extract  Trunk  192 
and  Channel  ID 


60  1 


IS  character  line  & 15  Inst  per  character 
25  inst/buffer  switch 
1 disk  access  for  overlay  p 50  Inst 


15  characters  P 4 Inst 
10  inst  to  decode  request 


10  Inst  for  linkage 
50  inst  for  disk  access 


4 levels  P 25  Inst 


1 CCSD  File  Access  P 2 disk  accesses 
8 character  field  P 10  inst/char  for  hash 
50  inst  for  directory  arbitration 


8 bytes  p 4 inst  - 


15 


ALGORITHM  - AS  (Continued) 

DESCRIPTION  - Retrieve  and  Display  CCSD  Connectivity  to  ACOC  Controller 


Processing 


ALGORITHM  - SI 

DESCRIPTION  - Sector  - Receipt  of  Fault  Notification  Broadcast  from  Sectors 


No.  N 
No.  Disk  Cl 

Inst.  Access  Displayed  | Rationale 


30  byte  msg  @ 2 inst/byte  for  error  processing 
25  inst/buffer  switch 
10  inst  to  decode  msg 
1 disk  access  for  overlay  @ 50  inst 


25  data  bytes  § 4 inst/byte 


5 severity  @ 5 inst/check 


2 disk  accesses  - 1 directory;  1 record  @ 
50  inst/access 

5 directories  @ 10  inst/dir  address  compute 
8 character  field  @ 10  lnst/char 


3 words  @ 10  inst/word 


1 word  @10  inst/word 


ALGORITHM  - SI  (Continued) 


DESCRIPTION  - Sector  - Receipt  of  Fault  Notification  Broadcast  from  Sectors 


No.  N 
No.  Disk  Cl 
Processing  Inst.  Access  Displayed 


Rationale 


10  inst  to  retrieve  form 
4 fields  to  Inst  @ 14  Inst  each 
3 Faults 


Modify  1 word  @ 10  inst  for  3 faults 


1 disk  access  @ 50  inst 
10  inst  for  linkage 


for  3 Faults 


Test  pointer  for  end-of-list  for  3 faults 


'W, 


ALGORITHM  - SI  (Continued) 


I 

I 


DESCRIPTION  - Sector  - Receipt  of  Fault  Notification  Broadcast  from  Sectors 


No. 

No. 

No. 

Disk 

Char 

Processing 

Inst. 

Access 

Displayed 

Rationale 

ALGORITHM  - S2  (Continued) 

DESCRIPTION  - Sector  - Receipt  of  Fault  Notification  Broadcast  from  ACOCa 


No.  N 
No.  Disk  C 
Inst.  Access  D 


Generate 

Discontinue 

Notification 


Modify  Fault 
Record  as 
Overridden 


10  inst  to  retrieve  form 
4 fields  to  inst  @ 14  inat  each 
3 Faults 


Modify  1 word  @ 10  inst  for  3 faults 


Restore  Fault. 
Record 


180  3 


1 disk  access  @ F0  inst 
10  inst  for  linkage 


for  3 Faults 


Test  pointer  for  end-of-list  for  3 faults 


ALGORITHM  - S3  (Continued) 


DESCRIPTION  - Sector  - Receipt  of  Fault  Notification  Broadcaat  from  Nodes 


No.  N 
No.  Disk  Cl 

Processing  | but.  Access  Displayed 


Isolation 

Indicator 

Update  10 


Restore 

Media 

Record 


DOD  Update  10 


1 word  @ 10  Inst 


1 word  @ 10  Inst 


10  Inst  for  linkage 
50  Inst  for  disk  access 


Retrieve  a 
Related  Fault 
Record  Under 
Controllers 


1 fault  file  access  @ 2 disk  accesses  - 100  Inst 
50  Inst  for  pointer  process 
For  3 Faults 


Precedence 

Severity 

Compare 


New  Fault 
Higher 


10  conditional  test  § 3 Inst  each 
For  3 Faults 


Generate 

Discontinue 

Notification 


10  inst  to  retrieve  form 
4 fields  to  Insert  @ 15  inst  each 
For  3 faults 


No. 

No.  Disk 
Inst.  Access  I Displayed 


Rationale 


Modify  1 word  @ 10  Inat  for  3 Faults 


1 disk  access  @ SO  Inst 
10  Inst  for  linkage 
For  3 faults 


Test  Pointer  for  End-of-Llst  for  3 Faults 


2 media  file  access  @ 2 disk  accesses  each  - 
200  Inst 

100  Inst  for  directory  arb 
5 Inst  to  extract  stations 
50  Inst  to  determine  node  routing 
4 sectors  @ 50  Inst  each  to  check  destination 


4 Nodes 
+ 4 Sectors 
+ 4 ACOC 


10  Inst  to  affix  destination 
10  Inst  to  affix  source 
50  Inst  to  move 


.... 


ALGORITHM  - S4 

DESCRIPTION  - Retrieve  and  Display  CCSD  Connectivity  to  Sector  Controller 


processing 


Input 

Handling 


Request 

Parsing 


No.  No. 

No.  Disk  Char 
Inst.  Access  Displayed 


IS  character  line  @ IS  inst  per  character 
25  inst/buffer  switch 
1 disk  access  for  overlay  @ 50  inst 


15  characters  @ 4 inst 
10  inst  to  decode  request 


Connectivity 

Overlay 

Retrieval 


10  inst  for  linkage 
50  inst  for  disk  access 


Retrieval  Type 
Check 


4 levels  @ 25  inst 


Retrieve 
CCSD  Record 


Extract  Trunk  192 
and  Channel  ID 


1 CCSD  File  Access  @ 2 disk  accesses 
8 character  field  @ 10  inst/char  for  hash 
50  inst  for  directory  arbitration 


8 bvtea  (a  -1  Inst  - 


tMKMTMi 
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ALGORITHM  - S4  (Continued) 

DESCRIPTION  - Retrieve  and  Display  CCSD  Connectivity  to  Sector  Controller 


Processing 


Retrieve  Trunk 
Record 


Determine 

Trunk 

Direction 


Extract  Station, 
Link  G/SC 


Append. 
Channel  # 


Format  Display 
Buffer 


No.  No. 

No.  Disk  Char 
Inst.  Access  Displayed 


Rationale 


1 Trunk  File  Access  @ 2 disk  accesses\_ 
6 character  field  @ 10  inst  for  hash  1 

50  inst  for  directory  arb  J 


25  inst  for  previous  station  check  - 


15  bytes  @ 4 inst  — 


2 characters  @ 5 inst  — 


15  character  data  line  @ 10  inst/character  J/ 
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DESCRIPTION  - Retrieve  end  Display  CCSD  Connectivity  to  Sector  Controller 


Processing 


No.  No. 

No.  Disk  Char 
Inst.  Access  Displayed 


Rationale 


ALGORITHM  - N1 


DESCRIPTION  - Node  - Receipt  of  a Fault  Notification  Broadcast  from  the  Sector 


ALGORITHM  - N1  (Continued) 

DESCRIPTION  - Node  - Receipt  of  a Fault  Notification  Broadcast  from  the  Sector 


Displayed 


Trunk  Status 


Retrieve 

Trunk 

Record 


Extract 
Trunk  in 
Connectivity 


3 words  @ 2 inst 


2 disk  access  @ 50  inst  each  \ 

6 char  field  @ 10  inst/char  for  hash 


Conditional  Test 


Processing 


Rationale 


Isolation 

Indication 

Update 


I word  @ 10  inst/word 


DOD 

Update 


1 word  @ 10  inst 


Restore 

Media 

Record  (CCSD) 


10  inst  for  linkage 
50  inst  for  disk  access 


ALGORITHM  - N1  (Conti nut J) 

DESCRIPTION  - Node  - Receipt  of  a Fault  Notification  Broadcast  from  the  Sector 


No. 

No.  Disk 

Processing  Inst.  Access 


Generate 
Notification 
Message 
for  Station 


20  character  line  @ 5 Inst/char—' 


Conditional  Test 


Conditional  Test- 


Ge  nerate 
ATEC  Status 
Request 


Schedule 
For  ATEC 
Output 


Conditional  Test 


10  Inst  to  retrieve  from 
3 fields  to  insert  @ 5 inst/field 


8 word  message  to  move  3 inst/word 
5 Inst  to  set  schedule  flag 
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ALGORITHM  - N2 

DESCRIPTION  - Node  - Accept  Fault  Entry  from  Stations 


Processing 


No. 

Inst. 


No. 
Disk 
Access 


No. 

Char 

Displayed 


' Rationale 


110 


30  byte  msg  @ 2 inst/byte  for  error  processing 
50  Inst  for  buffer  management 


80 


8 fields  @ 10  Inst 


200 


20  fields  @ 10  Inst 


Set  a Flag 


395 


A-37 


ALGORITHM  - N4 


DESCRIPTION  - Node  _ Accept  Fault  Entry  from  AUTODIN  Report  Prooessor 


No. 

No.  Disk 
Inst.  Access 


80  character  msg  @ 2 inat/byte  for  error 
processing 

1 disk  access  for  overlay  @ 50  Inst 


Fault  Data 
Parsing 


Generate 

Fault 

Record 


13  fields  @ 5 inst 


20  fields  @ 10  Inst 


. .. 


Schedule 

Output 

Processing 


Set  a flag 


ALGORITHM  - N6 


DESCRIPTION  - Node  - Perforin  Detailed  Fault  Entry  Processing 
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ALGORITHM  - NO  (Continued) 

DESCRIPTION  - Node  - Perform  Detailed  Fault  Entry  Processing 


No. 

No. 

Disk 

Processing 

Inat. 

Access 

Generate 
Notification  Mag 
for  Station 


r More 
Trunks? 


20  char  line  @ 5 lnst/char 


Conditional  Test  — 


Conditional  Test  - 


. : 
?: 


/ATECK, 

Monitor 

Equipped 


Generate  A TEC 
Status  Bequest 


Schedule  for 
A TEC  Output 


Conditional  Test 


10  Inst  to  retrieve  form 
3 fields  to  Insert  @ 5 lnst/field 


8 word  msg  @ 3 inst/word  to  move 
5 Inst  to  set  flag 
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